summaryrefslogtreecommitdiffstats
path: root/hw/pci
diff options
context:
space:
mode:
authorCindy Lu2021-02-25 17:55:06 +0100
committerMichael S. Tsirkin2021-03-02 12:09:54 +0100
commitfb592882397870a9eaf206f6c92789274ed07dda (patch)
treeea157512320eb70b31cb00163cd60b215abff56a /hw/pci
parenti386/acpi: restore device paths for pre-5.1 vms (diff)
downloadqemu-fb592882397870a9eaf206f6c92789274ed07dda.tar.gz
qemu-fb592882397870a9eaf206f6c92789274ed07dda.tar.xz
qemu-fb592882397870a9eaf206f6c92789274ed07dda.zip
virtio-net: handle zero mac for a vdpa peer
Some mlx vdpa devices with kernels at least up to 5.11 currently present 0 as their MAC address. This is because they have not been pre-configured with a MAC: they have a learning bridge and only learn the MAC once guest is up. Kernel patches and tools to allow programming the MAC from host are being developed. For now - since these combinations exist in the field - let's detect zero mac and just try to proceed with the mac from the qemu command line. This makes the guest use this MAC to send packets in turn teaching the MAC to the card, and things work. TODO: report the actual MAC from QEMU commad line in the info message. TODO: detect that a (non-zero) hardware MAC does not match QEMU command line and fail init. Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20210225165506.18321-2-lulu@redhat.com> mst: rewritten code comments, message printed and the commit log. Cc: Eli Cohen <elic@nvidia.com> Cc: Parav Pandit <parav@nvidia.com> Tested-by: Adrian Moreno <amorenoz@redhat.com> Tested-by: Sean Mooney <smooney@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'hw/pci')
0 files changed, 0 insertions, 0 deletions