search for: reset_map

...-314,6 +314,12 @@ struct vdpa_map_file { > >> * @iova: iova to be unmapped > >> * @size: size of the area > >> * Returns integer: success (0) or error (< 0) > >> + * @reset_map: Reset device memory mapping (optional) > >> + * Needed for device that using device > >> + * specific DMA translation (on-chip IOMMU) > > This exposes the device internal to the upper layer which is not...

...>>>> * @iova: iova to be unmapped >>>>>> * @size: size of the area >>>>>> * Returns integer: success (0) or error (< 0) >>>>>> + * @reset_map: Reset device memory mapping (optional) >>>>>> + * Needed for device that using device >>>>>> + * specific DMA translation (on-chip IOMMU) >>>>> This exposes the device interna...

...ardown 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 mapping without having to resort to the .reset() callback, which is mainly used to reset virtio specific device state. This new .reset_map() callback will be invoked only when the vhost-vdpa driver is to be removed and detached from the vdpa bus, such that ot...

...ardown 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 mapping without having to resort to the .reset() callback, which is mainly used to reset virtio specific device state. This new .reset_map() callback will be invoked only when the vhost-vdpa driver is to be removed and detached from the vdpa bus, such that ot...

...pped then reset back to the initial 1:1 DMA mapping. In order to reduce excessive memory mapping cost during live migration, it is desirable to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. mappings should be left intact across virtio device reset. Leverage the .reset_map callback to reset memory mapping, then the device .reset routine can run free from having to clean up memory mappings. Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> --- RFC v1 -> v2: - fix error path when both CVQ and DVQ fall in same asid --- drivers/vdpa/mlx5/core/mlx5_vdpa.h...

...git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index eabac06..71fbd559 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c @@ -131,6 +131,15 @@ static struct vhost_vdpa_as *vhost_vdpa_find_alloc_as(struct vhost_vdpa *v, return vhost_vdpa_alloc_as(v, asid); } +static void vhost_vdpa_reset_map(struct vhost_vdpa *v, u32 asid) +{ + struct vdpa_device *vdpa = v->vdpa; + const struct vdpa_config_ops *ops = vdpa->config; + + if (ops->reset_map) + ops->reset_map(vdpa, asid); +} + static int vhost_vdpa_remove_as(struct vhost_vdpa *v, u32 asid) { struct vhost_vdpa_as *as = asid_...

...*v) > >>>> +{ > >>>> + struct vdpa_device *vdpa = v->vdpa; > >>>> + const struct vdpa_config_ops *ops = vdpa->config; > >>>> + > >>>> + return (!ops->set_map && !ops->dma_map) || ops->reset_map; > >>> So this means the IOTLB/IOMMU mappings have already been decoupled > >>> from the vdpa reset. > >> Not in the sense of API, it' been coupled since day one from the > >> implementations of every on-chip IOMMU parent driver, namely mlx5_vdpa > &...

..._persistent_map(const struct vhost_vdpa *v) > >> +{ > >> + struct vdpa_device *vdpa = v->vdpa; > >> + const struct vdpa_config_ops *ops = vdpa->config; > >> + > >> + return (!ops->set_map && !ops->dma_map) || ops->reset_map; > > So this means the IOTLB/IOMMU mappings have already been decoupled > > from the vdpa reset. > Not in the sense of API, it' been coupled since day one from the > implementations of every on-chip IOMMU parent driver, namely mlx5_vdpa > and vdpa_sim. Because of that, late...

...(const struct vhost_vdpa *v) >>>> +{ >>>> + struct vdpa_device *vdpa = v->vdpa; >>>> + const struct vdpa_config_ops *ops = vdpa->config; >>>> + >>>> + return (!ops->set_map && !ops->dma_map) || ops->reset_map; >>> So this means the IOTLB/IOMMU mappings have already been decoupled >>> from the vdpa reset. >> Not in the sense of API, it' been coupled since day one from the >> implementations of every on-chip IOMMU parent driver, namely mlx5_vdpa >> and vdpa_sim. Bec...