search for: vhost_vdpa_iova_range

...*argp) > > return 0; > } > + > +static long vhost_vdpa_get_iova_range(struct vhost_vdpa *v, u32 __user *argp) > +{ > + struct iommu_domain_geometry geo; > + struct vdpa_device *vdpa = v->vdpa; > + const struct vdpa_config_ops *ops = vdpa->config; > + struct vhost_vdpa_iova_range range; > + struct vdpa_iova_range vdpa_range; > + > + if (!ops->set_map && !ops->dma_map) { Why not just check if (ops->get_iova_range) directly? > + iommu_domain_get_attr(v->domain, > + DOMAIN_ATTR_GEOMETRY, &geo); > + range.start = geo.ape...

...*argp) > > return 0; > } > + > +static long vhost_vdpa_get_iova_range(struct vhost_vdpa *v, u32 __user *argp) > +{ > + struct iommu_domain_geometry geo; > + struct vdpa_device *vdpa = v->vdpa; > + const struct vdpa_config_ops *ops = vdpa->config; > + struct vhost_vdpa_iova_range range; > + struct vdpa_iova_range vdpa_range; > + > + if (!ops->set_map && !ops->dma_map) { Why not just check if (ops->get_iova_range) directly? > + iommu_domain_get_attr(v->domain, > + DOMAIN_ATTR_GEOMETRY, &geo); > + range.start = geo.ape...

...a_set_config_call(struct vhost_vdpa *v, u32 __user *argp) return 0; } + +static long vhost_vdpa_get_iova_range(struct vhost_vdpa *v, u32 __user *argp) +{ + struct iommu_domain_geometry geo; + struct vdpa_device *vdpa = v->vdpa; + const struct vdpa_config_ops *ops = vdpa->config; + struct vhost_vdpa_iova_range range; + struct vdpa_iova_range vdpa_range; + + if (!ops->set_map && !ops->dma_map) { + iommu_domain_get_attr(v->domain, + DOMAIN_ATTR_GEOMETRY, &geo); + range.start = geo.aperture_start; + range.end = geo.aperture_end; + } else { + vdpa_range = ops->get_iova_ra...

...gt;> } >> + >> +static long vhost_vdpa_get_iova_range(struct vhost_vdpa *v, u32 __user *argp) >> +{ >> + struct iommu_domain_geometry geo; >> + struct vdpa_device *vdpa = v->vdpa; >> + const struct vdpa_config_ops *ops = vdpa->config; >> + struct vhost_vdpa_iova_range range; >> + struct vdpa_iova_range vdpa_range; >> + >> + if (!ops->set_map && !ops->dma_map) { > Why not just check if (ops->get_iova_range) directly? Because set_map || dma_ops is a hint that the device has its own DMA translation logic. Device without get...

...; > >>> int nvqs, > > >>> bool is_datapath, > > >>> bool svq, > > >>> - struct vhost_vdpa_iova_range iova_range, > > >>> - VhostIOVATree *iova_tree) > > >>> + struct vhost_vdpa_iova_range iova_range) > > >>> { > > >>> NetClientState *nc = NULL; > >...

Hi All: This series introduces API for reporing IOVA range. This is a must for userspace to work correclty: - for the process that uses vhost-vDPA directly to properly allocate IOVA - for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out of range - for VM(qemu), when vIOMMU is enabled, determine a valid guest address width Please review. Thanks Jason Wang (4): vdpa:

Hi All: This series introduces API for reporing IOVA range. This is a must for userspace to work correclty: - for the process that uses vhost-vDPA directly to properly allocate IOVA - for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out of range - for VM(qemu), when vIOMMU is enabled, determine a valid guest address width Please review. Thanks Jason Wang (4): vdpa:

...gt;> int nvqs, > > >>>> bool is_datapath, > > >>>> bool svq, > > >>>> - struct vhost_vdpa_iova_range iova_range) > > >>>> + struct vhost_vdpa_iova_range iova_range, > > >>>> + uint64_t features) > > >>>> { > > >>>> NetClientState *nc = NULL;...

Hi All: This series introduces API for reporing IOVA range. This is a must for userspace to work correclty: - for the process that uses vhost-vDPA directly to properly allocate IOVA - for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out of range - for VM(qemu), when vIOMMU is enabled, determine a valid guest address width Please review. Changes from V1: - do not mandate

...py_to_user(featurep, &features, sizeof(features))) r = -EFAULT; break; diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h index d3aad12a..6acc604 100644 --- a/include/uapi/linux/vhost_types.h +++ b/include/uapi/linux/vhost_types.h @@ -181,5 +181,10 @@ struct vhost_vdpa_iova_range { #define VHOST_BACKEND_F_SUSPEND 0x4 /* Device can be resumed */ #define VHOST_BACKEND_F_RESUME 0x5 +/* Device may expose the virtqueue's descriptor area, driver area and + * device area to a different group for ASID binding than where its + * buffers may reside. Requires VHOST_BACKEND_F_...

Following patchset introduces dedicated group for descriptor table to reduce live migration downtime when passthrough VQ is being switched to shadow VQ. This RFC v2 is sent to incorporate the early feedback from reviewers on the uAPI and driver API part of changes, the associated driver patch set consuming ths API will come around soon along with formal submission of this series. Some initial

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