search for: add_config

...nday, June 5, 2023 2:54 PM > > To: Angus Chen <angus.chen at jaguarmicro.com> > > Cc: mst at redhat.com; virtualization at lists.linux-foundation.org; > > linux-kernel at vger.kernel.org > > Subject: Re: [PATCH] vp_vdpa: Check queue number of vdpa device from > > add_config > > > > On Fri, Jun 2, 2023 at 3:35?PM Angus Chen <angus.chen at jaguarmicro.com> > > wrote: > > > > > > When add virtio_pci vdpa device,check the vqs number of device cap > > > and max_vq_pairs from add_config. > > > > > > Signed...

...- u8 mac[ETH_ALEN]; >> int err; >> int i; >> >> @@ -617,19 +618,18 @@ static int pds_vdpa_dev_add(struct vdpa_mgmt_dev *mdev, const char *name, >> * or set a random mac if default is 00:..:00 >> */ >> if (add_config->mask & BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR)) { >> - ether_addr_copy(mac, add_config->net.mac); >> - pds_vdpa_cmd_set_mac(pdsv, mac); >> + ether_addr_copy(pdsv->mac, add_config->net.mac); >> } else { >&g...

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

v2 for internal review - heavily reworked NET_F_MAC patch, matches recent PR-68875 - reordered to put "clean and reset vqs" before "alloc-irq" to make them slightly simpler patches - other minor cleanups for simpler patches These are some fixes for device providing a MAC address, for allocating irq resources later to support vhost use, and for properly cleaning vq info

v2 for internal review - heavily reworked NET_F_MAC patch, matches recent PR-68875 - reordered to put "clean and reset vqs" before "alloc-irq" to make them slightly simpler patches - other minor cleanups for simpler patches These are some fixes for device providing a MAC address, for allocating irq resources later to support vhost use, and for properly cleaning vq info

I want to start out with an apache class that will disable all modules except for a pre-defined list, thus establishing a baseline of active modules. Then as needed, other classes could enable a module that they require that would have been disabled by the baseline state. Its possible several classes may try to enable the same module (1 or more classes needing module1 could be on a single node)

...index 520646ae7fa0..502c482a93ce 100644 > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > @@ -3122,6 +3122,8 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name, > return -EINVAL; > } > device_features &= add_config->device_features; > + } else { > + device_features &= ~BIT_ULL(VIRTIO_NET_F_MRG_RXBUF); > } > if (!(device_features & BIT_ULL(VIRTIO_F_VERSION_1) && > device_features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM))) { > -- > 2.38.1

...index 4abc3a4ee515..3858ba1e8975 100644 > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > @@ -3154,6 +3154,8 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name, > return -EINVAL; > } > device_features &= add_config->device_features; > + } else { > + device_features &= ~BIT_ULL(VIRTIO_NET_F_MRG_RXBUF); > } > if (!(device_features & BIT_ULL(VIRTIO_F_VERSION_1) && > device_features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM))) { > -- > 2.38.1

...ivers/vdpa/mlx5/net/mlx5_vnet.c > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > > > @@ -3154,6 +3154,8 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name, > > > return -EINVAL; > > > } > > > device_features &= add_config->device_features; > > > + } else { > > > + device_features &= ~BIT_ULL(VIRTIO_NET_F_MRG_RXBUF); > > > } > > > if (!(device_features & BIT_ULL(VIRTIO_F_VERSION_1) && > > > device_features & BIT_ULL(VIRTIO_F_ACCESS_PL...

...private); > > @@ -3172,6 +3196,7 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name, > > init_mvqs(ndev); > init_rwsem(&ndev->reslock); > + spin_lock_init(&ndev->status_lock); > config = &ndev->config; > > if (add_config->mask & BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MTU)) { > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.h b/drivers/vdpa/mlx5/net/mlx5_vnet.h > index c90a89e1de4d..3666bbaa8822 100644 > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.h > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.h > @@ -50,6 +50,8 @@...

Live migration of vdpa would typically require re-instate vdpa device with an idential set of configs on the destination node, same way as how source node created the device in the first place. In order to allow live migration orchestration software to export the initial set of vdpa attributes with which the device was created, it will be useful if the vdpa tool can report the config on demand

..._id_table[] = { > >> + {VIRTIO_ID_NET, VIRTIO_DEV_ANY_ID}, > >> + {0}, > >> +}; > >> + > >> +static int pds_vdpa_dev_add(struct vdpa_mgmt_dev *mdev, const char *name, > >> + const struct vdpa_dev_set_config *add_config) > >> +{ > >> + return -EOPNOTSUPP; > >> +} > >> + > >> +static void pds_vdpa_dev_del(struct vdpa_mgmt_dev *mdev, > >> + struct vdpa_device *vdpa_dev) > >> +{ > >> +} > >> + > >&g...