similar to: [PATCH v3] vdpa/mlx5: should not activate virtq object when suspended

Displaying 20 results from an estimated 900 matches similar to: "[PATCH v3] vdpa/mlx5: should not activate virtq object when suspended"

2023 Feb 16
1
[PATCH v3] vdpa/mlx5: should not activate virtq object when suspended
On Wed, Feb 15, 2023 at 9:31 AM Si-Wei Liu <si-wei.liu at oracle.com> wrote: > > Otherwise the virtqueue object to instate could point to invalid address > that was unmapped from the MTT: > > mlx5_core 0000:41:04.2: mlx5_cmd_out_err:782:(pid 8321): > CREATE_GENERAL_OBJECT(0xa00) op_mod(0xd) failed, status > bad parameter(0x3), syndrome (0x5fa1c), err(-22) > >
2023 Feb 16
1
[PATCH v3] vdpa/mlx5: should not activate virtq object when suspended
On 2/15/2023 8:48 PM, Jason Wang wrote: > On Wed, Feb 15, 2023 at 9:31 AM Si-Wei Liu <si-wei.liu at oracle.com> wrote: >> Otherwise the virtqueue object to instate could point to invalid address >> that was unmapped from the MTT: >> >> mlx5_core 0000:41:04.2: mlx5_cmd_out_err:782:(pid 8321): >> CREATE_GENERAL_OBJECT(0xa00) op_mod(0xd) failed, status
2023 Aug 02
3
[PATCH 0/2] vdpa/mlx5: Fixes for ASID handling
This patch series is based on Eugenio's fix for handling CVQs in a different ASID [0]. The first patch is the actual fix. The next 2 patches are fixing a possible issue that I found while implementing patch 1. The patches are ordered like this for clarity. [0] https://lore.kernel.org/lkml/20230112142218.725622-1-eperezma at redhat.com/ Dragos Tatulea (1): vdpa/mlx5: Fix
2023 Aug 02
3
[PATCH 0/2] vdpa/mlx5: Fixes for ASID handling
This patch series is based on Eugenio's fix for handling CVQs in a different ASID [0]. The first patch is the actual fix. The next 2 patches are fixing a possible issue that I found while implementing patch 1. The patches are ordered like this for clarity. [0] https://lore.kernel.org/lkml/20230112142218.725622-1-eperezma at redhat.com/ Dragos Tatulea (1): vdpa/mlx5: Fix
2023 Sep 09
4
[PATCH RFC v2 0/4] vdpa: decouple reset of iotlb mapping from device reset
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
2023 Sep 09
4
[PATCH RFC v3 0/4] vdpa: decouple reset of iotlb mapping from device reset
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
2023 Sep 09
0
[PATCH RFC v2 2/4] vdpa/mlx5: implement .reset_map driver op
Today, mlx5_vdpa gets started by preallocate 1:1 DMA mapping at device creation time, while this 1:1 mapping will be implicitly destroyed when the first .set_map call is invoked. Everytime when the .reset callback is invoked, any mapping left behind will be dropped then reset back to the initial 1:1 DMA mapping. In order to reduce excessive memory mapping cost during live migration, it is
2020 Jul 16
0
[PATCH vhost next 10/10] vdpa/mlx5: Add VDPA driver for supported mlx5 devices
On 2020/7/16 ??3:23, Eli Cohen wrote: > Add a front end VDPA driver that registers in the VDPA bus and provides > networking to a guest. The VDPA driver creates the necessary resources > on the VF it is driving such that data path will be offloaded. > > Notifications are being communicated through the driver. > > Currently, only VFs are supported. In subsequent patches we will
2023 Apr 03
0
[Patch v3] vdpa/mlx5: Avoid losing link state updates
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 > >>
2023 Jul 04
1
[PATCH] mlx5_vdpa: offer VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK
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
2023 Jan 16
0
[PATCH 5/5] vdpa: mlx5: support per virtqueue dma device
On Sun, Jan 15, 2023 at 7:08 PM Eli Cohen <elic at nvidia.com> wrote: > > > From: Jason Wang <jasowang at redhat.com> > > Sent: Wednesday, 11 January 2023 8:28 > > To: mst at redhat.com; jasowang at redhat.com > > Cc: Eli Cohen <elic at nvidia.com>; gdawar at amd.com; > > virtualization at lists.linux-foundation.org; linux-kernel at
2020 Sep 28
0
[PATCH V1 vhost-next] vdpa/mlx5: Make vdpa core driver a distinct module
On Thu, Sep 24, 2020 at 05:32:31PM +0300, Eli Cohen wrote: > Change core vdpa functionality into a loadbale module such that upcoming > block implementation will be able to use it. > > Signed-off-by: Eli Cohen <elic at nvidia.com> Why don't we merge this patch together with the block module? > --- > V0 --> V1: > Removed "default n" for configu options
2020 Sep 29
0
[PATCH V1 vhost-next] vdpa/mlx5: Make vdpa core driver a distinct module
On Tue, Sep 29, 2020 at 09:20:26AM +0300, Eli Cohen wrote: > On Mon, Sep 28, 2020 at 03:55:09PM -0400, Michael S. Tsirkin wrote: > > On Thu, Sep 24, 2020 at 05:32:31PM +0300, Eli Cohen wrote: > > > Change core vdpa functionality into a loadbale module such that upcoming > > > block implementation will be able to use it. > > > > > > Signed-off-by: Eli
2020 Sep 29
0
[PATCH V1 vhost-next] vdpa/mlx5: Make vdpa core driver a distinct module
On Tue, Sep 29, 2020 at 09:34:33AM +0300, Eli Cohen wrote: > On Tue, Sep 29, 2020 at 02:26:44AM -0400, Michael S. Tsirkin wrote: > > On Tue, Sep 29, 2020 at 09:20:26AM +0300, Eli Cohen wrote: > > > On Mon, Sep 28, 2020 at 03:55:09PM -0400, Michael S. Tsirkin wrote: > > > > On Thu, Sep 24, 2020 at 05:32:31PM +0300, Eli Cohen wrote: > > > > > Change core
2020 Sep 29
0
[PATCH V1 vhost-next] vdpa/mlx5: Make vdpa core driver a distinct module
On Tue, Sep 29, 2020 at 09:57:44AM +0300, Eli Cohen wrote: > On Tue, Sep 29, 2020 at 02:51:12AM -0400, Michael S. Tsirkin wrote: > > On Tue, Sep 29, 2020 at 09:34:33AM +0300, Eli Cohen wrote: > > > On Tue, Sep 29, 2020 at 02:26:44AM -0400, Michael S. Tsirkin wrote: > > > > On Tue, Sep 29, 2020 at 09:20:26AM +0300, Eli Cohen wrote: > > > > > On Mon, Sep
2020 Aug 21
3
[PATCH] vdpa/mlx5: Avoid warnings about shifts on 32-bit platforms
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,
2020 Aug 21
3
[PATCH] vdpa/mlx5: Avoid warnings about shifts on 32-bit platforms
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,
2023 Feb 06
7
[PATCH v4 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:
2023 Feb 03
6
[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:
2023 Mar 27
0
[PATCH] vdpa/mlx5: Avoid losing link state updates
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