qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Cindy Lu <lulu@redhat.com>, Jason Wang <jasowang@redhat.com>,
	Parav Pandit <parav@nvidia.com>, Sean Mooney <smooney@redhat.com>,
	Eli Cohen <elic@nvidia.com>, Adrian Moreno <amorenoz@redhat.com>
Subject: [PULL 2/4] virtio-net: handle zero mac for a vdpa peer
Date: Tue, 2 Mar 2021 09:21:13 -0500	[thread overview]
Message-ID: <20210302142014.141135-3-mst@redhat.com> (raw)
In-Reply-To: <20210302142014.141135-1-mst@redhat.com>

From: Cindy Lu <lulu@redhat.com>

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>
---
 hw/net/virtio-net.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 439f823b19..96a3cc8357 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -126,6 +126,7 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
     VirtIONet *n = VIRTIO_NET(vdev);
     struct virtio_net_config netcfg;
     NetClientState *nc = qemu_get_queue(n->nic);
+    static const MACAddr zero = { .a = { 0, 0, 0, 0, 0, 0 } };
 
     int ret = 0;
     memset(&netcfg, 0 , sizeof(struct virtio_net_config));
@@ -151,6 +152,17 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
         ret = vhost_net_get_config(get_vhost_net(nc->peer), (uint8_t *)&netcfg,
                                    n->config_size);
         if (ret != -1) {
+            /*
+             * Some NIC/kernel combinations present 0 as the mac address.  As
+             * that is not a legal address, try to proceed with the
+             * address from the QEMU command line in the hope that the
+             * address has been configured correctly elsewhere - just not
+             * reported by the device.
+             */
+            if (memcmp(&netcfg.mac, &zero, sizeof(zero)) == 0) {
+                info_report("Zero hardware mac address detected. Ignoring.");
+                memcpy(netcfg.mac, n->mac, ETH_ALEN);
+            }
             memcpy(config, &netcfg, n->config_size);
         }
     }
-- 
MST



  parent reply	other threads:[~2021-03-02 14:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 14:21 [PULL 0/4] pc,virtio,pci: bug fixes Michael S. Tsirkin
2021-03-02 14:21 ` [PULL 1/4] i386/acpi: restore device paths for pre-5.1 vms Michael S. Tsirkin
2021-03-02 14:21 ` Michael S. Tsirkin [this message]
2021-03-02 14:21 ` [PULL 3/4] hw/pci: Have safer pcie_bus_realize() by checking error path Michael S. Tsirkin
2021-03-02 14:21 ` [PULL 4/4] vhost: simplify vhost_dev_init() fail_busyloop label Michael S. Tsirkin
2021-03-03 18:10 ` [PULL 0/4] pc,virtio,pci: bug fixes Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210302142014.141135-3-mst@redhat.com \
    --to=mst@redhat.com \
    --cc=amorenoz@redhat.com \
    --cc=elic@nvidia.com \
    --cc=jasowang@redhat.com \
    --cc=lulu@redhat.com \
    --cc=parav@nvidia.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=smooney@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).