search for: set_map

...VALIDATE > 3) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_END flag As long as we are extending the interface, is there some way we could cut down the number of system calls needed here? > > Vhost-vdpa may decide to batch the IOMMU/IOTLB updating in step 3 when > vDPA device support set_map() ops. This is useful for the vDPA device > that want to know all the mappings to tweak their own DMA translation > logic. > > For vDPA device that doesn't require set_map(), no behavior changes. > > This capability is advertised via VHOST_BACKEND_F_IOTLB_BATCH capability. &...

...VALIDATE > 3) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_END flag As long as we are extending the interface, is there some way we could cut down the number of system calls needed here? > > Vhost-vdpa may decide to batch the IOMMU/IOTLB updating in step 3 when > vDPA device support set_map() ops. This is useful for the vDPA device > that want to know all the mappings to tweak their own DMA translation > logic. > > For vDPA device that doesn't require set_map(), no behavior changes. > > This capability is advertised via VHOST_BACKEND_F_IOTLB_BATCH capability. &...

Hi all: This series tries to support batched IOTLB updating vhost-vdpa. Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it can only forward one mapping to IOMMU or device through IOMMU API or dma_map(). Though set_map() is deisgend to have the capability to pass an rbtree based mapping to vDPA device, it's still be called at least once for each VHOST_IOTLB_UPDATE or VHOST_IOTLB_INVALIDATE. This is because vhost-vdpa doesn't know the userspace start or stop then updating. So this patch introduces two fla...

...t all changes take place atomically after BATCH_END? If atomically, we might need to limit batch size to make sure kernel can keep a copy in memory. > > > > > > > > Vhost-vdpa may decide to batch the IOMMU/IOTLB updating in step 3 when > > > vDPA device support set_map() ops. This is useful for the vDPA device > > > that want to know all the mappings to tweak their own DMA translation > > > logic. > > > > > > For vDPA device that doesn't require set_map(), no behavior changes. > > > > > > This capability...

Hi all: This series tries to support batched IOTLB updating vhost-vdpa. Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it can only forward one mapping to IOMMU or device through IOMMU API or dma_map(). Though set_map() is designed to have the capability to pass an rbtree based mapping to vDPA device, it's still be called at least once for each VHOST_IOTLB_UPDATE or VHOST_IOTLB_INVALIDATE. This is because vhost-vdpa doesn't know the userspace start or stop then updating. So this patch introduces two fla...

...a batch, it may do: 1) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_BEGIN flag 2) Perform a batch of IOTLB updating via VHOST_IOTLB_UPDATE/INVALIDATE 3) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_END flag Vhost-vdpa may decide to batch the IOMMU/IOTLB updating in step 3 when vDPA device support set_map() ops. This is useful for the vDPA device that want to know all the mappings to tweak their own DMA translation logic. For vDPA device that doesn't require set_map(), no behavior changes. This capability is advertised via VHOST_BACKEND_F_IOTLB_BATCH capability. Signed-off-by: Jason Wang <...

...e? I'm not sure it's worth to do that since usually we only have less than 10 regions. A possible method is to carry multiple vhost_iotlb_message in one system call. > > >> Vhost-vdpa may decide to batch the IOMMU/IOTLB updating in step 3 when >> vDPA device support set_map() ops. This is useful for the vDPA device >> that want to know all the mappings to tweak their own DMA translation >> logic. >> >> For vDPA device that doesn't require set_map(), no behavior changes. >> >> This capability is advertised via VHOST_BACKEND_F_IOT...

...;> +static bool vhost_vdpa_has_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 d...

...vdpa_has_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...

...t;> > >> +static bool vhost_vdpa_has_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...

...wo types of devices: 1) device without on-chip IOMMU, DMA was done via IOMMU API which only support incremental map/unmap 2) device with on-chip IOMMU, DMA could be done by device driver itself, and we could choose to pass the whole mappings to the driver at one time through vDPA bus operation (set_map) For vhost-vpda, there're two types of memory mapping: a) memory table, setup by userspace through VHOST_SET_MEM_TABLE, the whole mapping is updated in this way b) IOTLB API, incrementally done by userspace through vhost message (IOTLB_UPDATE/IOTLB_INVALIDATE) The current design is: - Reu...

...wo types of devices: 1) device without on-chip IOMMU, DMA was done via IOMMU API which only support incremental map/unmap 2) device with on-chip IOMMU, DMA could be done by device driver itself, and we could choose to pass the whole mappings to the driver at one time through vDPA bus operation (set_map) For vhost-vpda, there're two types of memory mapping: a) memory table, setup by userspace through VHOST_SET_MEM_TABLE, the whole mapping is updated in this way b) IOTLB API, incrementally done by userspace through vhost message (IOTLB_UPDATE/IOTLB_INVALIDATE) The current design is: - Reu...

...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...

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:

...t;>>> * @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...

...e will help much here. Qemu still need to wait for all the DMA is setup to let guest work. > >> 2) device with on-chip IOMMU, DMA could be done by device driver itself, and >> we could choose to pass the whole mappings to the driver at one time through >> vDPA bus operation (set_map) >> >> For vhost-vpda, there're two types of memory mapping: >> >> a) memory table, setup by userspace through VHOST_SET_MEM_TABLE, the whole >> mapping is updated in this way >> b) IOTLB API, incrementally done by userspace through vhost message >> (IO...

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is

...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.aperture_start; > + range.end = geo.aperture_end; > + } else { > + vdpa_rang...