search for: get_vq_dma_dev

...i > > > > > Thanks > > > >> + * @vdev: vdpa device > >> + * @asid: address space identifier > >> + * Returns integer: success (0) or error (< 0) > >> * @get_vq_dma_dev: Get the dma device for a specific > >> * virtqueue (optional) > >> * @vdev: vdpa device > >> @@ -390,6 +396,7 @@ struct vdpa_config_ops { > >> u64 iova, u64 size, u6...

...llback. (optional) + * @vdev: vdpa device * @free: Free resources that belongs to vDPA (optional) * @vdev: vdpa device */ @@ -351,6 +359,8 @@ struct vdpa_config_ops { int (*set_group_asid)(struct vdpa_device *vdev, unsigned int group, unsigned int asid); struct device *(*get_vq_dma_dev)(struct vdpa_device *vdev, u16 idx); + int (*bind_mm)(struct vdpa_device *vdev, struct mm_struct *mm); + void (*unbind_mm)(struct vdpa_device *vdev); /* Free device resources */ void (*free)(struct vdpa_device *vdev); -- 2.39.2

...t;>>>>> + * @vdev: vdpa device >>>>>> + * @asid: address space identifier >>>>>> + * Returns integer: success (0) or error (< 0) >>>>>> * @get_vq_dma_dev: Get the dma device for a specific >>>>>> * virtqueue (optional) >>>>>> * @vdev: vdpa device >>>>>> @@ -390,6 +396,7 @@ struct vdpa_config_ops { >>>>>&gt...

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

...orker_thread+0x50/0x3a0 > > ? rescuer_thread+0x390/0x390 > > kthread+0xd6/0x100 > > ? kthread_complete_and_exit+0x20/0x20 > > ret_from_fork+0x1f/0x30 > > </TASK> > > > > Signed-off-by: Jason Wang <jasowang at redhat.com> > > mlx5_get_vq_dma_dev needs to made static. Right, I will fix it in v2. > Other than that: > Reviewed-by: Eli Cohen <elic at nvidia.com> > Tested-by: <elic at nvidia.com> Thanks > > Reviewed-by: Eli Cohen <elic at nvidia.com> > Tested-by: <elic at nvidia.com> > > --- &...

...unsigned int asid) +{ + struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev); + struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev); + int err; + + down_write(&ndev->reslock); + err = mlx5_vdpa_reset_mr(mvdev, asid); + up_write(&ndev->reslock); + return err; +} + static struct device *mlx5_get_vq_dma_dev(struct vdpa_device *vdev, u16 idx) { struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev); @@ -3162,6 +3169,7 @@ static int mlx5_set_group_asid(struct vdpa_device *vdev, u32 group, .set_config = mlx5_vdpa_set_config, .get_generation = mlx5_vdpa_get_generation, .set_map = mlx5_vdpa_set_map, + .rese...

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the

v2: - rebased on Linus' tree, commit ae3419fbac84 ("vc_screen: don't clobber return value in vcs_read") - removed `struct task_struct *owner` param (unused for now, maybe ?useful to support cgroups) [Jason] - add unbind_mm callback [Jason] - call the new unbind_mm callback during the release [Jason] - avoid to call bind_mm callback after the reset, since the device ?is not

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the