Re: VDPA MAC address problem

[Jason Wang <jasowang@redhat.com>]

On Fri, Mar 21, 2025 at 12:29 PM Konstantin Shkolnyy <kshk@linux.ibm.com> wrote:
>
> On 3/20/2025 20:22, Jason Wang wrote:
> > On Fri, Mar 21, 2025 at 12:45 AM Konstantin Shkolnyy <kshk@linux.ibm.com> wrote:
> >>
> >> On 3/19/2025 19:58, Jason Wang wrote:
> >>> On Thu, Mar 20, 2025 at 12:34 AM Konstantin Shkolnyy <kshk@linux.ibm.com> wrote:
> >>>> 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.
> >>>
> >>> VHOST_VDPA_SET_CONFIG requires the vDPA parent support which is not
> >>> necessarily there.
> >>
> >> The mlx5 driver doesn't do anything for VHOST_VDPA_SET_CONFIG. Intel's
> >> driver, however, apparently stores the configuration. So, it appears,
> >> Intel will avoid the problem... Perhaps mlx5 could do the same so that
> >> QEMU can set the address before it starts the VM (QEMU doesn't have to
> >> later let the VM change the config).
> >
> > The problem is that config space is not allowed to be written, that is
> > why mlx5 doesn't implement the write method.
> >
> >> Conceptually, setting the address
> >> by QEMU cmdline doesn't look different from setting it by "vdpa dev add".
> >
> > It's kind of different.
> >
> > E.g the device may not even have VIRTIO_NET_F_MAC feature etc.
>
> I'm not sure I understand... This is the MAC address returned by
> VHOST_VDPA_GET_CONFIG. If mlx5 allows it to be set by "vdpa dev add",

This requires privileges where userspace(VM) doesn't necessarily have.

> shouldn't it also allow it to be set by VHOST_VDPA_SET_CONFIG called by
> virtio_net_device_realize(), before the VM exists.
>
> When VM starts running, it queries this MAC address and QEMU fetches it
> by VHOST_VDPA_GET_CONFIG. But, because VHOST_VDPA_SET_CONFIG hasn't
> stored it, it fetches a wrong stale address.

For example, for some reason management wants to forbid mac address
changes from the guest.

Thanks