similar to: [PATCH v3 0/6] features provisioning fixes and mlx5_vdpa support

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:

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

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

On Tue, Mar 21, 2023 at 01:28:08PM +0200, Eli Cohen wrote: > Following patch adds driver support for VIRTIO_NET_F_MRG_RXBUF. > > Current firmware versions show degradation in packet rate when using > MRG_RXBUF. Users who favor memory saving over packet rate could enable > this feature but we want to keep it off by default. > > One can still enable it when creating the vdpa

On 7/7/23 12:33 AM, Jason Wang wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > On Fri, Jun 30, 2023 at 8:36?AM Shannon Nelson <shannon.nelson at amd.com> wrote: >> >> From: Allen Hubbe <allen.hubbe at amd.com> >> >> When the vdpa device is reset,

Clang warns several times when building for 32-bit ARM along the lines of: drivers/vdpa/mlx5/net/mlx5_vnet.c:1462:31: warning: shift count >= width of type [-Wshift-count-overflow] ndev->mvdev.mlx_features |= BIT(VIRTIO_F_VERSION_1); ^~~~~~~~~~~~~~~~~~~~~~~ This is related to the BIT macro, which uses an unsigned long literal,

Clang warns several times when building for 32-bit ARM along the lines of: drivers/vdpa/mlx5/net/mlx5_vnet.c:1462:31: warning: shift count >= width of type [-Wshift-count-overflow] ndev->mvdev.mlx_features |= BIT(VIRTIO_F_VERSION_1); ^~~~~~~~~~~~~~~~~~~~~~~ This is related to the BIT macro, which uses an unsigned long literal,

On Mon, Apr 3, 2023 at 2:47?PM Eli Cohen <elic at nvidia.com> wrote: > > > On 03/04/2023 8:01, Jason Wang wrote: > > On Sun, Apr 2, 2023 at 10:15?PM Eli Cohen <elic at nvidia.com> wrote: > >> Current code ignores link state updates if VIRTIO_NET_F_STATUS was not > >> negotiated. However, link state updates could be received before feature > >>

On Mon, Mar 20, 2023 at 10:01:05AM +0200, Eli Cohen wrote: > Current code ignores link state updates if VIRTIO_NET_F_STATUS was not > negotiated. However, link state updates could be received before feature > negotiation was completed , therefore causing link state events to be > lost, possibly leaving the link state down. > > Add code to detect if VIRTIO_NET_F_STATUS was set

On Tue, Jun 6, 2023 at 2:19?PM Angus Chen <angus.chen at jaguarmicro.com> wrote: > > Hi,Jason. > > > -----Original Message----- > > From: Jason Wang <jasowang at redhat.com> > > Sent: Monday, 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; >

The spec says: status only exists if VIRTIO_NET_F_STATUS is set Similar to MAC and MTU, vdpa_dev_net_config_fill() should read STATUS conditionally depending on the feature bits. Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> --- drivers/vdpa/vdpa.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c

In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device should implement a separate .reset_map() operation callback to restore 1:1 DMA

In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device should implement a separate .reset_map() operation callback to restore 1:1 DMA

On Sun, Mar 12, 2023 at 10:39:19AM +0200, Eli Cohen wrote: > One can still enable it when creating the vdpa device using vdpa tool by > providing features that include it. > > For example: > $ vdpa dev add name vdpa0 mgmtdev pci/0000:86:00.2 device_features 0x300cb982b > > Signed-off-by: Eli Cohen <elic at nvidia.com> What's the reason to turn it off by default?

On Sun, Mar 12, 2023 at 11:10:25AM +0200, Eli Cohen wrote: > > On 12/03/2023 10:58, Michael S. Tsirkin wrote: > > On Sun, Mar 12, 2023 at 10:39:19AM +0200, Eli Cohen wrote: > > > One can still enable it when creating the vdpa device using vdpa tool by > > > providing features that include it. > > > > > > For example: > > > $ vdpa dev add

On Sun, Mar 12, 2023 at 4:41?PM Eli Cohen <elic at nvidia.com> wrote: > > When deleting the vdpa device, the debugfs files need to be removed so > need to remove debugfs after the device has been unregistered. > > This fixes null pointer dereference when someone deletes the device > after debugfs has been populated. > > Fixes: 294221004322 ("vdpa/mlx5: Add

On 7/3/2023 8:46 AM, Michael S. Tsirkin wrote: > On Mon, Jul 03, 2023 at 04:25:14PM +0200, Eugenio P?rez wrote: >> Offer this backend feature as mlx5 is compatible with it. It allows it >> to do live migration with CVQ, dynamically switching between passthrough >> and shadow virtqueue. >> >> Signed-off-by: Eugenio P?rez <eperezma at redhat.com> > Same