search for: iommu_unmap

...a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c @@ -322,8 +322,9 @@ gk20a_instobj_dtor_iommu(struct nvkm_memory *memory) /* Unmap pages from GPU address space and free them */ for (i = 0; i < node->base.mem.size; i++) { - iommu_unmap(imem->domain, - (r->offset + i) << imem->iommu_pgshift, PAGE_SIZE); + iommu_unmap_sync(imem->domain, + (r->offset + i) << imem->iommu_pgshift, + PAGE_SIZE); dma_unmap_page(dev, node->dma_addrs[i], PAGE_SIZE, DMA_BIDIRECTIONAL); __free...

...y tests run fine when QEMU is bound to a single CPU, even > though vcpu and viommu run in different threads > > > What to do then? Queue in software and wake up task. > > Unfortunately I can't do anything here, because IOMMU drivers can't > sleep in the iommu_map() or iommu_unmap() path. > > The problem is the same > for all IOMMU drivers. That's because the DMA API allows drivers to call > some functions with interrupts disabled. For example > Documentation/DMA-API-HOWTO.txt allows dma_alloc_coherent() and > dma_unmap_single() to be called in interrup...

...y tests run fine when QEMU is bound to a single CPU, even > though vcpu and viommu run in different threads > > > What to do then? Queue in software and wake up task. > > Unfortunately I can't do anything here, because IOMMU drivers can't > sleep in the iommu_map() or iommu_unmap() path. > > The problem is the same > for all IOMMU drivers. That's because the DMA API allows drivers to call > some functions with interrupts disabled. For example > Documentation/DMA-API-HOWTO.txt allows dma_alloc_coherent() and > dma_unmap_single() to be called in interrup...

...ost_vdpa_map > > > iommu_map > > > > > > 3. kill QEMU > > > > > > 4. vhost_vdpa_release > > > vhost_vdpa_free_domain > > > > > > In this case, we have no opportunity to invoke unpin_user_pages or > > > iommu_unmap to free the memory. > > > > We do: > > > > vhost_vdpa_cleanup() > > vhost_vdpa_remove_as() > > vhost_vdpa_iotlb_unmap() > > vhost_vdpa_pa_unmap() > > unpin_user_pages() > > vhost_vdp...

..., even > >> though vcpu and viommu run in different threads > >> > >>> What to do then? Queue in software and wake up task. > >> > >> Unfortunately I can't do anything here, because IOMMU drivers can't > >> sleep in the iommu_map() or iommu_unmap() path. > >> > >> The problem is the same > >> for all IOMMU drivers. That's because the DMA API allows drivers to call > >> some functions with interrupts disabled. For example > >> Documentation/DMA-API-HOWTO.txt allows dma_alloc_coherent() and &gt...

..., even > >> though vcpu and viommu run in different threads > >> > >>> What to do then? Queue in software and wake up task. > >> > >> Unfortunately I can't do anything here, because IOMMU drivers can't > >> sleep in the iommu_map() or iommu_unmap() path. > >> > >> The problem is the same > >> for all IOMMU drivers. That's because the DMA API allows drivers to call > >> some functions with interrupts disabled. For example > >> Documentation/DMA-API-HOWTO.txt allows dma_alloc_coherent() and &gt...

Add a flush_iotlb_range to allow flushing of an iova range instead of a full flush in the dma-iommu path. Allow the iommu_unmap_fast to return newly freed page table pages and pass the freelist to queue_iova in the dma-iommu ops path. This patch is useful for iommu drivers (in this case the intel iommu driver) which need to wait for the ioTLB to be flushed before newly free/unmapped page table pages can be freed. This way...

Add a flush_iotlb_range to allow flushing of an iova range instead of a full flush in the dma-iommu path. Allow the iommu_unmap_fast to return newly freed page table pages and pass the freelist to queue_iova in the dma-iommu ops path. This patch is useful for iommu drivers (in this case the intel iommu driver) which need to wait for the ioTLB to be flushed before newly free/unmapped page table pages can be freed. This way...

...mmu run in different threads > >>>> > >>>>> What to do then? Queue in software and wake up task. > >>>> > >>>> Unfortunately I can't do anything here, because IOMMU drivers can't > >>>> sleep in the iommu_map() or iommu_unmap() path. > >>>> > >>>> The problem is the same > >>>> for all IOMMU drivers. That's because the DMA API allows drivers to call > >>>> some functions with interrupts disabled. For example > >>>> Documentation/DMA-API-HOWTO...

Allow the iommu_unmap_fast to return newly freed page table pages and pass the freelist to queue_iova in the dma-iommu ops path. This is useful for iommu drivers (in this case the intel iommu driver) which need to wait for the ioTLB to be flushed before newly free/unmapped page table pages can be freed. This way we can...

Add a flush_iotlb_range to allow flushing of an iova range instead of a full flush in the dma-iommu path. Allow the iommu_unmap_fast to return newly freed page table pages and pass the freelist to queue_iova in the dma-iommu ops path. This patch is useful for iommu drivers (in this case the intel iommu driver) which need to wait for the ioTLB to be flushed before newly free/unmapped page table pages can be freed. This way...

...> 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); > } > > @@ -655,6 +661,8 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev, > struct vhost_iotlb_msg *msg) > { > struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev); > + struct vdpa_device *vdpa = v->vdpa; &...

...> 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); > } > > @@ -655,6 +661,8 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev, > struct vhost_iotlb_msg *msg) > { > struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev); > + struct vdpa_device *vdpa = v->vdpa; &...

On 2020-08-18 07:04, Tom Murphy wrote: > Add a flush_iotlb_range to allow flushing of an iova range instead of a > full flush in the dma-iommu path. > > Allow the iommu_unmap_fast to return newly freed page table pages and > pass the freelist to queue_iova in the dma-iommu ops path. > > This patch is useful for iommu drivers (in this case the intel iommu > driver) which need to wait for the ioTLB to be flushed before newly > free/unmapped page table page...

...list_first_entry(&_node->mem->regions, struct nvkm_mm_node, + rl_entry); + + /* clear bit 34 to unmap pages */ + r->offset &= ~BIT(34 - priv->iommu_pgshift); + + /* Unmap pages from GPU address space and free them */ + for (i = 0; i < _node->mem->size; i++) { + iommu_unmap(priv->domain, + (r->offset + i) << priv->iommu_pgshift, PAGE_SIZE); + __free_page(node->pages[i]); + } + + /* Release area from GPU address space */ + mutex_lock(priv->mm_mutex); + nvkm_mm_free(priv->mm, &r); + mutex_unlock(priv->mm_mutex); +} + +static void +g...

...QEMU is bound to a single CPU, even >> though vcpu and viommu run in different threads >> >>> What to do then? Queue in software and wake up task. >> >> Unfortunately I can't do anything here, because IOMMU drivers can't >> sleep in the iommu_map() or iommu_unmap() path. >> >> The problem is the same >> for all IOMMU drivers. That's because the DMA API allows drivers to call >> some functions with interrupts disabled. For example >> Documentation/DMA-API-HOWTO.txt allows dma_alloc_coherent() and >> dma_unmap_single()...

...running another task right? My tests run fine when QEMU is bound to a single CPU, even though vcpu and viommu run in different threads > What to do then? Queue in software and wake up task. Unfortunately I can't do anything here, because IOMMU drivers can't sleep in the iommu_map() or iommu_unmap() path. The problem is the same for all IOMMU drivers. That's because the DMA API allows drivers to call some functions with interrupts disabled. For example Documentation/DMA-API-HOWTO.txt allows dma_alloc_coherent() and dma_unmap_single() to be called in interrupt context. > As kick is vm...

...> > - 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); > > > } > > > @@ -655,6 +661,8 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev, > > > struct vhost_iotlb_msg *msg) > > > { > > > struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev);...

...;> though vcpu and viommu run in different threads >>>> >>>>> What to do then? Queue in software and wake up task. >>>> >>>> Unfortunately I can't do anything here, because IOMMU drivers can't >>>> sleep in the iommu_map() or iommu_unmap() path. >>>> >>>> The problem is the same >>>> for all IOMMU drivers. That's because the DMA API allows drivers to call >>>> some functions with interrupts disabled. For example >>>> Documentation/DMA-API-HOWTO.txt allows dma_alloc_coh...

...t ath11k_base *ab) ret = iommu_map(iommu_dom, ab_ahb->fw.ce_paddr, ab_ahb->fw.ce_paddr, ab_ahb->fw.ce_size, - IOMMU_READ | IOMMU_WRITE); + IOMMU_READ | IOMMU_WRITE, GFP_KERNEL); if (ret) { ath11k_err(ab, "failed to map firmware CE region: %d\n", ret); goto err_iommu_unmap; diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 1cd4815a6dd197..80072b6b628358 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -643,7 +643,8 @@ static int rproc_handle_devmem(struct rproc *rproc, void *p...