search for: dma_unmap

...+ ret = 0; > } > > return ret; > @@ -501,6 +504,9 @@ nv_device_unmap_page(struct nouveau_device *device, dma_addr_t addr) > if (nv_device_is_pci(device)) > pci_unmap_page(device->pdev, addr, PAGE_SIZE, > PCI_DMA_BIDIRECTIONAL); pci_map/unmap alias to dma_unmap/map when called on the underlying struct device embedded in pci_device (like for platform drivers). Dunno whether it's worth to track a pointer to the struct device directly and always call dma_unmap/map. Just drive-by comment since I'm interested in how you solve this - i915 has similar f...

...Map an area of PA to IOVA (optional) > * Needed for device that using device > * specific DMA translation (on-chip IOMMU) > * and preferring incremental map. > : > : > * @dma_unmap: Unmap an area of IOVA (optional but > * must be implemented with dma_map) > * Needed for device that using device > * specific DMA translation (on-chip IOMMU) > *...

...ouveau_device *device, >>> dma_addr_t addr) >>> if (nv_device_is_pci(device)) >>> pci_unmap_page(device->pdev, addr, PAGE_SIZE, >>> PCI_DMA_BIDIRECTIONAL); >> >> >> pci_map/unmap alias to dma_unmap/map when called on the underlying struct >> device embedded in pci_device (like for platform drivers). Dunno whether >> it's worth to track a pointer to the struct device directly and always >> call dma_unmap/map. > > > Isn't it (theoretically) possible to have a...

...t; diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c > index de211ef3738c..ab7af978ef70 100644 > --- a/drivers/vdpa/vdpa.c > +++ b/drivers/vdpa/vdpa.c > @@ -82,6 +82,10 @@ struct vdpa_device *__vdpa_alloc_device(struct device *parent, > if (!!config->dma_map != !!config->dma_unmap) > goto err; > > + if ((config->dma_map || config->set_map) && > + !config->get_iova_range) > + goto err; > + > err = -ENOMEM; > vdev = kzalloc(size, GFP_KERNEL); > if (!vdev) What about devices using an IOMMU for translation? IOMMUs gene...

...> return ret; >> @@ -501,6 +504,9 @@ nv_device_unmap_page(struct nouveau_device *device, dma_addr_t addr) >> if (nv_device_is_pci(device)) >> pci_unmap_page(device->pdev, addr, PAGE_SIZE, >> PCI_DMA_BIDIRECTIONAL); > > pci_map/unmap alias to dma_unmap/map when called on the underlying struct > device embedded in pci_device (like for platform drivers). Dunno whether > it's worth to track a pointer to the struct device directly and always > call dma_unmap/map. Isn't it (theoretically) possible to have a platform that does not use...

...>> dma_addr_t addr) >>>> if (nv_device_is_pci(device)) >>>> pci_unmap_page(device->pdev, addr, PAGE_SIZE, >>>> PCI_DMA_BIDIRECTIONAL); >>> >>> >>> pci_map/unmap alias to dma_unmap/map when called on the underlying struct >>> device embedded in pci_device (like for platform drivers). Dunno whether >>> it's worth to track a pointer to the struct device directly and always >>> call dma_unmap/map. >> >> >> Isn't it (theoretica...

...Needed for device that using device >>>> * specific DMA translation (on-chip IOMMU) >>>> * and preferring incremental map. >>>> : >>>> : >>>> * @dma_unmap: Unmap an area of IOVA (optional but >>>> * must be implemented with dma_map) >>>> * Needed for device that using device >>>> * specific DMA transl...

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

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

...s->set_map(vdpa, dev->iotlb); > + } else > r = iommu_map(v->domain, iova, pa, size, > perm_to_iommu_flags(perm)); > > @@ -559,9 +564,10 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size) > > if (ops->dma_map) > ops->dma_unmap(vdpa, iova, size); > - else if (ops->set_map) > - ops->set_map(vdpa, dev->iotlb); > - else > + else if (ops->set_map) { > + if (!v->in_batch) > + ops->set_map(vdpa, dev->iotlb); > + } else > iommu_unmap(v->domain, iova, size); > } > &g...

...s->set_map(vdpa, dev->iotlb); > + } else > r = iommu_map(v->domain, iova, pa, size, > perm_to_iommu_flags(perm)); > > @@ -559,9 +564,10 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size) > > if (ops->dma_map) > ops->dma_unmap(vdpa, iova, size); > - else if (ops->set_map) > - ops->set_map(vdpa, dev->iotlb); > - else > + else if (ops->set_map) { > + if (!v->in_batch) > + ops->set_map(vdpa, dev->iotlb); > + } else > iommu_unmap(v->domain, iova, size); > } > &g...

...ops which will be called by the generic mdev emulation code. Currently, the vdpa device ops are defined as: typedef int (*vdpa_start_device_t)(struct vdpa_dev *vdpa); typedef int (*vdpa_stop_device_t)(struct vdpa_dev *vdpa); typedef int (*vdpa_dma_map_t)(struct vdpa_dev *vdpa); typedef int (*vdpa_dma_unmap_t)(struct vdpa_dev *vdpa); typedef int (*vdpa_set_eventfd_t)(struct vdpa_dev *vdpa, int vector, int fd); typedef u64 (*vdpa_supported_features_t)(struct vdpa_dev *vdpa); typedef void (*vdpa_notify_device_t)(struct vdpa_dev *vdpa, int qid); typedef u64 (*vdpa_get_notify_addr_t)(struct vdpa_dev *vdpa...

...ops which will be called by the generic mdev emulation code. Currently, the vdpa device ops are defined as: typedef int (*vdpa_start_device_t)(struct vdpa_dev *vdpa); typedef int (*vdpa_stop_device_t)(struct vdpa_dev *vdpa); typedef int (*vdpa_dma_map_t)(struct vdpa_dev *vdpa); typedef int (*vdpa_dma_unmap_t)(struct vdpa_dev *vdpa); typedef int (*vdpa_set_eventfd_t)(struct vdpa_dev *vdpa, int vector, int fd); typedef u64 (*vdpa_supported_features_t)(struct vdpa_dev *vdpa); typedef void (*vdpa_notify_device_t)(struct vdpa_dev *vdpa, int qid); typedef u64 (*vdpa_get_notify_addr_t)(struct vdpa_dev *vdpa...

...eneric mdev emulation code. > > Currently, the vdpa device ops are defined as: > > typedef int (*vdpa_start_device_t)(struct vdpa_dev *vdpa); > typedef int (*vdpa_stop_device_t)(struct vdpa_dev *vdpa); > typedef int (*vdpa_dma_map_t)(struct vdpa_dev *vdpa); > typedef int (*vdpa_dma_unmap_t)(struct vdpa_dev *vdpa); > typedef int (*vdpa_set_eventfd_t)(struct vdpa_dev *vdpa, int vector, int fd); > typedef u64 (*vdpa_supported_features_t)(struct vdpa_dev *vdpa); > typedef void (*vdpa_notify_device_t)(struct vdpa_dev *vdpa, int qid); > typedef u64 (*vdpa_get_notify_addr_t)(s...

...e changed, 4 insertions(+) diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c index de211ef3738c..ab7af978ef70 100644 --- a/drivers/vdpa/vdpa.c +++ b/drivers/vdpa/vdpa.c @@ -82,6 +82,10 @@ struct vdpa_device *__vdpa_alloc_device(struct device *parent, if (!!config->dma_map != !!config->dma_unmap) goto err; + if ((config->dma_map || config->set_map) && + !config->get_iova_range) + goto err; + err = -ENOMEM; vdev = kzalloc(size, GFP_KERNEL); if (!vdev) -- 2.20.1

...t struct vdpa_config_ops vdpasim_net_config_ops = { .get_config = vdpasim_get_config, .set_config = vdpasim_set_config, .get_generation = vdpasim_get_generation, + .get_iova_range = vdpasim_get_iova_range, .dma_map = vdpasim_dma_map, .dma_unmap = vdpasim_dma_unmap, .free = vdpasim_free, @@ -683,6 +694,7 @@ static const struct vdpa_config_ops vdpasim_net_batch_config_ops = { .get_config = vdpasim_get_config, .set_config = vdpasim_set_config, .get_generation = vdpasim_ge...

...+ } else > > > r = iommu_map(v->domain, iova, pa, size, > > > perm_to_iommu_flags(perm)); > > > @@ -559,9 +564,10 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size) > > > if (ops->dma_map) > > > ops->dma_unmap(vdpa, iova, size); > > > - else if (ops->set_map) > > > - ops->set_map(vdpa, dev->iotlb); > > > - else > > > + else if (ops->set_map) { > > > + if (!v->in_batch) > > > + ops->set_map(vdpa, dev->iotlb); > > > + }...

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:

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