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