search for: dev_features

...> } > > -enum { MLX5_VIRTIO_NET_F_GUEST_CSUM = 1 << 9, > - MLX5_VIRTIO_NET_F_CSUM = 1 << 10, > - MLX5_VIRTIO_NET_F_HOST_TSO6 = 1 << 11, > - MLX5_VIRTIO_NET_F_HOST_TSO4 = 1 << 12, > -}; > - > static u64 mlx_to_vritio_features(u16 dev_features) > { > u64 result = 0; > > - if (dev_features & MLX5_VIRTIO_NET_F_GUEST_CSUM) > + if (dev_features & BIT_ULL(MLX5_VIRTIO_NET_F_MRG_RXBUF)) > + result += BIT_ULL(VIRTIO_NET_F_MRG_RXBUF); > + if (dev_features & BIT_ULL(MLX5_VIR...

...ATAVQ_GROUP; > } > > -enum { MLX5_VIRTIO_NET_F_GUEST_CSUM = 1 << 9, > - MLX5_VIRTIO_NET_F_CSUM = 1 << 10, > - MLX5_VIRTIO_NET_F_HOST_TSO6 = 1 << 11, > - MLX5_VIRTIO_NET_F_HOST_TSO4 = 1 << 12, > -}; > - > static u64 mlx_to_vritio_features(u16 dev_features) > { > u64 result = 0; > > - if (dev_features & MLX5_VIRTIO_NET_F_GUEST_CSUM) > + if (dev_features & BIT_ULL(MLX5_VIRTIO_NET_F_MRG_RXBUF)) > + result += BIT_ULL(VIRTIO_NET_F_MRG_RXBUF); > + if (dev_features & BIT_ULL(MLX5_VIRTIO_NET_F_HOST_ECN)) > + res...

...(!!(features & BIT_ULL(VIRTIO_NET_F_CSUM)) << 7) | + (!!(features & BIT_ULL(VIRTIO_NET_F_GUEST_CSUM)) << 6); } static int create_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *mvq) @@ -1439,13 +1439,13 @@ static u64 mlx_to_vritio_features(u16 dev_features) u64 result = 0; if (dev_features & MLX5_VIRTIO_NET_F_GUEST_CSUM) - result |= BIT(VIRTIO_NET_F_GUEST_CSUM); + result |= BIT_ULL(VIRTIO_NET_F_GUEST_CSUM); if (dev_features & MLX5_VIRTIO_NET_F_CSUM) - result |= BIT(VIRTIO_NET_F_CSUM); + result |= BIT_ULL(VIRTIO_NET_F_CSUM); if (...

...(!!(features & BIT_ULL(VIRTIO_NET_F_CSUM)) << 7) | + (!!(features & BIT_ULL(VIRTIO_NET_F_GUEST_CSUM)) << 6); } static int create_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *mvq) @@ -1439,13 +1439,13 @@ static u64 mlx_to_vritio_features(u16 dev_features) u64 result = 0; if (dev_features & MLX5_VIRTIO_NET_F_GUEST_CSUM) - result |= BIT(VIRTIO_NET_F_GUEST_CSUM); + result |= BIT_ULL(VIRTIO_NET_F_GUEST_CSUM); if (dev_features & MLX5_VIRTIO_NET_F_CSUM) - result |= BIT(VIRTIO_NET_F_CSUM); + result |= BIT_ULL(VIRTIO_NET_F_CSUM); if (...

...BIT_ULL(VIRTIO_NET_F_CSUM)) << 7) | > + (!!(features & BIT_ULL(VIRTIO_NET_F_GUEST_CSUM)) << 6); > } > > static int create_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *mvq) > @@ -1439,13 +1439,13 @@ static u64 mlx_to_vritio_features(u16 dev_features) > u64 result = 0; > > if (dev_features & MLX5_VIRTIO_NET_F_GUEST_CSUM) > - result |= BIT(VIRTIO_NET_F_GUEST_CSUM); > + result |= BIT_ULL(VIRTIO_NET_F_GUEST_CSUM); > if (dev_features & MLX5_VIRTIO_NET_F_CSUM) > - result |= BIT(VIRTIO_NET_F_CSUM); > + resu...

This commit implements a new function ifcvf_get_driver_feature() which read driver_features from virtio registers. To be less ambiguous, ifcvf_set_features() is renamed to ifcvf_set_driver_features(), and ifcvf_get_features() is renamed to ifcvf_get_dev_features() which returns the provisioned vDPA device features. Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> --- drivers/vdpa/ifcvf/ifcvf_base.c | 38 +++++++++++++++++---------------- drivers/vdpa/ifcvf/ifcvf_base.h | 5 +++-- drivers/vdpa/ifcvf/ifcvf_main.c | 9 +++++--- 3 files change...

...9;t sync vq address in set_vq_address()). >> >> >>> +static u64 mlx5_vdpa_get_features(struct vdpa_device *vdev) >>> +{ >>> + struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev); >>> + struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev); >>> + u16 dev_features; >>> + >>> + dev_features = MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, device_features_bits_mask); >>> + ndev->mvdev.mlx_features = mlx_to_vritio_features(dev_features); >>> + if (MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, virtio_version_1_0)) >>> +...

...| ^~~~~~~~~~~~~ include/linux/mlx5/device.h:1364:2: note: in expansion of macro 'MLX5_GET' 1364 | MLX5_GET(device_virtio_emulation_cap, \ | ^~~~~~~~ drivers/vdpa/mlx5/net/mlx5_vnet.c:1469:17: note: in expansion of macro 'MLX5_CAP_DEV_VDPA_EMULATION' 1469 | dev_features = MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, device_features_bits_mask); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/mlx5/qp.h:36, from drivers/vdpa/mlx5/net/mlx5_vnet.c:7: include/linux/mlx5/device.h:50:57: error: 'struc...

In below example, before the fix, mtu attribute is supported by the parent mgmtdev, but the error message showing "All provided are not supported" is just misleading. $ vdpa mgmtdev show vdpasim_net: supported_classes net max_supported_vqs 3 dev_features MTU MAC CTRL_VQ CTRL_MAC_ADDR ANY_LAYOUT VERSION_1 ACCESS_PLATFORM $ vdpa dev add mgmtdev vdpasim_net name vdpasim0 mtu 5000 max_vqp 2 Error: vdpa: All provided attributes are not supported. kernel answers: Operation not supported After fix, the relevant error message will be like: $ vdpa dev ad...

This commit implements a new function ifcvf_get_driver_feature() which read driver_features from virtio registers. To be less ambiguous, ifcvf_set_features() is renamed to ifcvf_set_driver_features(), and ifcvf_get_features() is renamed to ifcvf_get_dev_features() which returns the provisioned vDPA device features. Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> --- drivers/vdpa/ifcvf/ifcvf_base.c | 38 +++++++++++++++++---------------- drivers/vdpa/ifcvf/ifcvf_base.h | 5 +++-- drivers/vdpa/ifcvf/ifcvf_main.c | 9 +++++--- 3 files change...

...turn PAGE_SIZE; > +} > + > +enum { MLX5_VIRTIO_NET_F_GUEST_CSUM = 1 << 9, > + MLX5_VIRTIO_NET_F_CSUM = 1 << 10, > + MLX5_VIRTIO_NET_F_HOST_TSO6 = 1 << 11, > + MLX5_VIRTIO_NET_F_HOST_TSO4 = 1 << 12, > +}; > + > +static u64 mlx_to_vritio_features(u16 dev_features) > +{ > + u64 result = 0; > + > + if (dev_features & MLX5_VIRTIO_NET_F_GUEST_CSUM) > + result |= BIT(VIRTIO_NET_F_GUEST_CSUM); > + if (dev_features & MLX5_VIRTIO_NET_F_CSUM) > + result |= BIT(VIRTIO_NET_F_CSUM); > + if (dev_features & MLX5_VIRTIO_NET_F_HOST_TSO...

...e the device defaults. > If user doesn?t supply any feature fits, that means user wants to run with some device defaults. > In that case its fine to run with device defaults. Noted, we don't have this device defaults exposed to users yet other than what's shown in the parent mgmtdev (dev_features). And the current and the only safe behavior for mlx5_vdpa is to inherit all device supported features from parent mgmtdev, otherwise user can't know in advance what default features the device might come up with implicitly underneath. Basically it would need to add new CLI interface to ach...

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:

Formerly, ifcvf driver has implemented a lazy-initialization mechanism for the virtqueues and other config space contents, it would store all configurations that passed down from the userspace, then load them to the device config space upon DRIVER_OK. This can not serve live migration, so this series implement an immediate initialization mechanism, which means rather than the former store-load

Formerly, ifcvf driver has implemented a lazy-initialization mechanism for the virtqueues and other config space contents, it would store all configurations that passed down from the userspace, then load them to the device config space upon DRIVER_OK. This can not serve live migration, so this series implement an immediate initialization mechanism, which means rather than the former store-load

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