search for: iommu_dma_ops

...2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7 at tcd.ie/ > > What about others? E.g. PPC? That was the point I was getting at - while iommu-dma should build just fine for the likes of PPC, s390, 32-bit Arm, etc., they have no architecture code to correctly wire up iommu_dma_ops to devices. Thus there's currently no point pulling it in and pretending it's anything more than a waste of space for architectures other than arm64 and x86. It's merely a historical artefact of the x86 DMA API implementation that when the IOMMU drivers were split out to form driver...

...2] https://lore.kernel.org/linux-iommu/20191221150402.13868-1-murphyt7 at tcd.ie/ > > What about others? E.g. PPC? That was the point I was getting at - while iommu-dma should build just fine for the likes of PPC, s390, 32-bit Arm, etc., they have no architecture code to correctly wire up iommu_dma_ops to devices. Thus there's currently no point pulling it in and pretending it's anything more than a waste of space for architectures other than arm64 and x86. It's merely a historical artefact of the x86 DMA API implementation that when the IOMMU drivers were split out to form driver...

...inux-iommu/20191221150402.13868-1-murphyt7 at tcd.ie/ > > > > What about others? E.g. PPC? > > That was the point I was getting at - while iommu-dma should build just fine > for the likes of PPC, s390, 32-bit Arm, etc., they have no architecture code > to correctly wire up iommu_dma_ops to devices. Thus there's currently no > point pulling it in and pretending it's anything more than a waste of space > for architectures other than arm64 and x86. It's merely a historical > artefact of the x86 DMA API implementation that when the IOMMU drivers were > split ou...

..._noncoherent NULL +#define iommu_dma_free_noncoherent NULL +#endif /* CONFIG_DMA_REMAP */ + static int iommu_dma_mmap(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, dma_addr_t dma_addr, size_t size, unsigned long attrs) @@ -1122,6 +1153,8 @@ static const struct dma_map_ops iommu_dma_ops = { .free = iommu_dma_free, .alloc_pages = dma_common_alloc_pages, .free_pages = dma_common_free_pages, + .alloc_noncoherent = iommu_dma_alloc_noncoherent, + .free_noncoherent = iommu_dma_free_noncoherent, .mmap = iommu_dma_mmap, .get_sgtable = iommu_dma_get_sgtable, .map_page =...

...uct virtio_device *vdev) +{ + struct device *dev = vdev->dev.parent; + const struct dma_map_ops *dma_ops = &arm64_swiotlb_dma_ops; + + if (virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) + return; + + dev->archdata.dma_coherent = true; + if (iommu_get_domain_for_dev(dev)) + dma_ops = &iommu_dma_ops; + + set_dma_ops(dev, dma_ops); +} +#endif /* CONFIG_VIRTIO */ -- 2.1.4

On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: > On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote: > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: > > > With the built-in topology description in place, x86 platforms can now > > > use the virtio-iommu. > > > > > > Signed-off-by: Jean-Philippe Brucker

On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote: > On Fri, Feb 14, 2020 at 04:57:11PM +0000, Robin Murphy wrote: > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote: > > > With the built-in topology description in place, x86 platforms can now > > > use the virtio-iommu. > > > > > > Signed-off-by: Jean-Philippe Brucker

...diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 5141d49a046baa..00a5b49248e334 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -1120,6 +1120,8 @@ static unsigned long iommu_dma_get_merge_boundary(struct device *dev) static const struct dma_map_ops iommu_dma_ops = { .alloc = iommu_dma_alloc, .free = iommu_dma_free, + .alloc_pages = dma_common_alloc_pages, + .free_pages = dma_common_free_pages, .mmap = iommu_dma_mmap, .get_sgtable = iommu_dma_get_sgtable, .map_page = iommu_dma_map_page, diff --git a/drivers/iommu/intel/iommu.c b/drivers/...

...diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 4959f5df21bd07..3da06df0f327c2 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -1120,6 +1120,8 @@ static unsigned long iommu_dma_get_merge_boundary(struct device *dev) static const struct dma_map_ops iommu_dma_ops = { .alloc = iommu_dma_alloc, .free = iommu_dma_free, + .alloc_pages = dma_common_alloc_pages, + .free_pages = dma_common_free_pages, .mmap = iommu_dma_mmap, .get_sgtable = iommu_dma_get_sgtable, .map_page = iommu_dma_map_page, diff --git a/drivers/iommu/intel/iommu.c b/drivers/...

This patch series is the follow up on the discussions we had before about the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation for virito devices (https://patchwork.kernel.org/patch/10417371/). There were suggestions about doing away with two different paths of transactions with the host/QEMU, first being the direct GPA and the other being the DMA API based translations.

This patch series is the follow up on the discussions we had before about the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation for virito devices (https://patchwork.kernel.org/patch/10417371/). There were suggestions about doing away with two different paths of transactions with the host/QEMU, first being the direct GPA and the other being the DMA API based translations.

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. As a follow up I

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a