Displaying 5 results from an estimated 5 matches for "mlx5_vdpa_cvq_group".
2023 Sep 09
0
[PATCH RFC v2 2/4] vdpa/mlx5: implement .reset_map driver op
....c
@@ -489,21 +489,15 @@ static void destroy_user_mr(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *mr
}
}
-static void _mlx5_vdpa_destroy_cvq_mr(struct mlx5_vdpa_dev *mvdev, unsigned int asid)
+static void _mlx5_vdpa_destroy_cvq_mr(struct mlx5_vdpa_dev *mvdev)
{
- if (mvdev->group2asid[MLX5_VDPA_CVQ_GROUP] != asid)
- return;
-
prune_iotlb(mvdev);
}
-static void _mlx5_vdpa_destroy_dvq_mr(struct mlx5_vdpa_dev *mvdev, unsigned int asid)
+static void _mlx5_vdpa_destroy_dvq_mr(struct mlx5_vdpa_dev *mvdev)
{
struct mlx5_vdpa_mr *mr = &mvdev->mr;
- if (mvdev->group2asid[MLX5_VDPA_DATAV...
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