On Fri, Mar 21, 2025 at 12:29 PM Konstantin Shkolnyy <k...@linux.ibm.com> wrote: > > On 3/20/2025 20:22, Jason Wang wrote: > > On Fri, Mar 21, 2025 at 12:45 AM Konstantin Shkolnyy <k...@linux.ibm.com> > > wrote: > >> > >> On 3/19/2025 19:58, Jason Wang wrote: > >>> On Thu, Mar 20, 2025 at 12:34 AM Konstantin Shkolnyy <k...@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
