On Wed, 28 Aug 2024 at 17:37, Dragos Tatulea <dtatu...@nvidia.com> wrote: > > > > On 28.08.24 11:00, Cindy Lu wrote: > > On Wed, 28 Aug 2024 at 09:51, Jason Wang <jasow...@redhat.com> wrote: > >> > >> On Wed, Aug 28, 2024 at 12:03 AM Dragos Tatulea <dtatu...@nvidia.com> > >> wrote: > >>> > >>> When the vdpa device is configured without a specific MAC > >>> address, the vport MAC address is used. However, this > >>> address can be 0 which prevents the driver from properly > >>> configuring the MPFS and breaks steering. > >>> > >>> The solution is to simply generate a random MAC address > >>> when no MAC is set on the nic vport. > >>> > >>> Now it's possible to create a vdpa device without a > >>> MAC address and run qemu with this device without needing > >>> to configure an explicit MAC address. > >>> > >>> Signed-off-by: Dragos Tatulea <dtatu...@nvidia.com> > >>> Reviewed-by: Jiri Pirko <j...@nvidia.com> > >> > >> Acked-by: Jason Wang <jasow...@redhat.com> > >> > >> (Adding Cindy for double checking if it has any side effect on Qemu side) > >> > >> Thanks > >> > > But Now there is a bug in QEMU: if the hardware MAC address does not > > match the one in the QEMU command line, it will cause traffic loss. > > > Why is this a new issue in qemu? qemu in it's current state won't work > with a different mac address that the one that is set in HW anyway. > this is not a new bug. We are trying to fix it because it will cause traffic lose without any warning. in my fix , this setting (different mac in device and Qemu) will fail to load the VM.
> > So, Just an FYI here: if your patch merged, it may cause traffic loss. > > and now I'm working in the fix it in qemu, the link is > > https://patchew.org/QEMU/20240716011349.821777-1-l...@redhat.com/ > > The idea of this fix is > > There are will only two acceptable situations for qemu: > > 1. The hardware MAC address is the same as the MAC address specified > > in the QEMU command line, and both MAC addresses are not 0. > > 2. The hardware MAC address is not 0, and the MAC address in the QEMU > > command line is 0. In this situation, the hardware MAC address will > > overwrite the QEMU command line address. > > > Why would this not work with this patch? This patch simply sets a MAC > if the vport doesn't have one set. Which allows for more scenarios to > work. > I do not mean your patch will not work, I just want to make some clarify here.Your patch + my fix may cause the VM to fail to load in some situations, and this is as expected. Your patch is good to merge. Thanks cindy > Thanks, > Dragos > > > Thanks > > Cindy > > > > > >>> --- > >>> drivers/vdpa/mlx5/net/mlx5_vnet.c | 3 +++ > >>> 1 file changed, 3 insertions(+) > >>> > >>> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c > >>> b/drivers/vdpa/mlx5/net/mlx5_vnet.c > >>> index fa78e8288ebb..1c26139d02fe 100644 > >>> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c > >>> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > >>> @@ -3824,6 +3824,9 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev > >>> *v_mdev, const char *name, > >>> err = mlx5_query_nic_vport_mac_address(mdev, 0, 0, > >>> config->mac); > >>> if (err) > >>> goto err_alloc; > >>> + > >>> + if (is_zero_ether_addr(config->mac)) > >>> + eth_random_addr(config->mac); > >>> } > >>> > >>> if (!is_zero_ether_addr(config->mac)) { > >>> -- > >>> 2.45.1 > >>> > >> > > >
