qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Konstantin Shkolnyy <kshk@linux.ibm.com>
To: qemu-devel@nongnu.org
Cc: Jason Wang <jasowang@redhat.com>, dtatulea@nvidia.com
Subject: VDPA MAC address problem
Date: Wed, 19 Mar 2025 11:34:26 -0500	[thread overview]
Message-ID: <553b11b5-4cc4-4e59-9211-74c8cce51a96@linux.ibm.com> (raw)

I’m observing a problem while testing VDPA with Nvidia ConnectX-6 (mlx5) 
on s390.

Upon start, virtio_net_device_realize() tries to set a new MAC address 
by VHOST_VDPA_SET_CONFIG which doesn’t do anything.

Later, the VM gets started and learns about the old address from 
virtio_net_get_config() which returns whatever VHOST_VDPA_GET_CONFIG 
returns, unless it's "6 zero bytes", in which case it instead returns 
the desired new address (and the problem is avoided).

Then QEMU again tries to set the new address from vhost_net_start(), now 
by calling vhost_vdpa_net_load_cmd(...,VIRTIO_NET_CTRL_MAC, 
VIRTIO_NET_CTRL_MAC_ADDR_SET, ...). This time the new address is 
successfully programmed into the NIC, but the VM doesn't know about it.

As the result, the VM now sends packets with a source address on which 
the NIC doesn’t listen.

Upon reading this forum, I see that VHOST_VDPA_SET_CONFIG is 
“deprecated”, and so VIRTIO_NET_CTRL_MAC_ADDR_SET must be the right 
method, but it’s apparently called too late. Or maybe 
virtio_net_get_config() needs to always return the desired new address 
and not the old one from VHOST_VDPA_GET_CONFIG?

I’m looking for an opinion/direction from someone who knows this code.

As it is, the only VDPA scenario that's working for me is:
1) Avoid specifying the MAC address in the "vdpa dev add" command (which 
will create the "6 zero bytes" condition on the first launch).
2) Keep using the same MAC address for every subsequent VM launch on the 
same NIC "virtual function" (so that the old and new addresses are the 
same).


             reply	other threads:[~2025-03-19 16:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19 16:34 Konstantin Shkolnyy [this message]
2025-03-20  0:58 ` VDPA MAC address problem Jason Wang
2025-03-20  6:54   ` Eugenio Perez Martin
2025-03-20 13:59     ` Konstantin Shkolnyy
2025-03-20  9:14   ` Cindy Lu
2025-03-20 14:18   ` Konstantin Shkolnyy
2025-03-21  1:23     ` Jason Wang
2025-03-20 16:45   ` Konstantin Shkolnyy
2025-03-21  1:22     ` Jason Wang
2025-03-21  4:29       ` Konstantin Shkolnyy
2025-03-21  6:18         ` Cindy Lu
2025-03-24  4:04         ` Jason Wang

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=553b11b5-4cc4-4e59-9211-74c8cce51a96@linux.ibm.com \
    --to=kshk@linux.ibm.com \
    --cc=dtatulea@nvidia.com \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).