Displaying 13 results from an estimated 13 matches for "vhost_vdpa_iova_rang".
Did you mean:
vhost_vdpa_iova_range
2020 Aug 05
2
[PATCH 4/4] vhost: vdpa: report 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.ap...
2020 Aug 05
2
[PATCH 4/4] vhost: vdpa: report 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.ap...
2020 Jun 17
0
[PATCH 4/4] vhost: vdpa: report iova range
...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_r...
2020 Aug 06
0
[PATCH 4/4] vhost: vdpa: report iova range
...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 ge...
2023 Mar 06
0
[PATCH v4 01/15] vdpa net: move iova tree creation from init to start
...; > >>> 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;
> >...
2020 Jun 17
12
[PATCH 0/4] vDPA: API for reporting IOVA range
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:
2020 Jun 17
12
[PATCH 0/4] vDPA: API for reporting IOVA range
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:
2023 Mar 06
0
[PATCH v4 12/15] vdpa: block migration if device has unsupported features
...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;...
2020 Aug 21
9
[PATCH V2 0/3] vDPA: API for reporting IOVA range
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
2023 Sep 09
0
[PATCH RFC v2 2/3] vhost-vdpa: introduce descriptor group backend feature
...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...
2023 Sep 09
4
[PATCH RFC v2 0/3] vdpa: dedicated descriptor table group
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
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