search for: dma_iommu_ops

On Wed, Sep 03, 2014 at 06:53:33AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote: > > > > On x86, at least, I doubt that we'll ever see a physically addressed > > PCI virtio device for which ACPI advertises an IOMMU, since any sane > > hypervisor will just not advertise an IOMMU for the virtio device. > > But

On Wed, Sep 03, 2014 at 06:53:33AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote: > > > > On x86, at least, I doubt that we'll ever see a physically addressed > > PCI virtio device for which ACPI advertises an IOMMU, since any sane > > hypervisor will just not advertise an IOMMU for the virtio device. > > But

...g to *actually* implement it on Linux? > Are you adding a new set of DMA APIs that do everything except > translation? Actually it's the opposite. There's nothing to do in the guest besides setting up SWIOTLB and sharing its buffer with the host. Normally on pseries, devices use the dma_iommu_ops defined in arch/powerpc/kernel/dma-iommu.c. I have a patch which changes the device's dma_ops to NULL so that the default DMA path will be used: https://lore.kernel.org/linuxppc-dev/20190713060023.8479-12-bauerman at linux.ibm.com/ Then another patch forces use of SWIOTLB and defines the set_...

...g to *actually* implement it on Linux? > Are you adding a new set of DMA APIs that do everything except > translation? Actually it's the opposite. There's nothing to do in the guest besides setting up SWIOTLB and sharing its buffer with the host. Normally on pseries, devices use the dma_iommu_ops defined in arch/powerpc/kernel/dma-iommu.c. I have a patch which changes the device's dma_ops to NULL so that the default DMA path will be used: https://lore.kernel.org/linuxppc-dev/20190713060023.8479-12-bauerman at linux.ibm.com/ Then another patch forces use of SWIOTLB and defines the set_...

...ux? > > Are you adding a new set of DMA APIs that do everything except > > translation? > > Actually it's the opposite. There's nothing to do in the guest besides > setting up SWIOTLB and sharing its buffer with the host. > > Normally on pseries, devices use the dma_iommu_ops defined in > arch/powerpc/kernel/dma-iommu.c. I have a patch which changes the > device's dma_ops to NULL so that the default DMA path will be used: > > https://lore.kernel.org/linuxppc-dev/20190713060023.8479-12-bauerman at linux.ibm.com/ > > Then another patch forces use o...

Michael S. Tsirkin <mst at redhat.com> writes: > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> I rephrased it in terms of address translation. What do you think of >>

Michael S. Tsirkin <mst at redhat.com> writes: > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin <mst at redhat.com> writes: >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> I rephrased it in terms of address translation. What do you think of >>

...ma_common_free_pages, }; EXPORT_SYMBOL(jazz_dma_ops); diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c index 569fecd7b5b234..d4e702d74b3393 100644 --- a/arch/powerpc/kernel/dma-iommu.c +++ b/arch/powerpc/kernel/dma-iommu.c @@ -137,4 +137,6 @@ const struct dma_map_ops dma_iommu_ops = { .get_required_mask = dma_iommu_get_required_mask, .mmap = dma_common_mmap, .get_sgtable = dma_common_get_sgtable, + .alloc_pages = dma_common_alloc_pages, + .free_pages = dma_common_free_pages, }; diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/syst...

...ma_common_free_pages, }; EXPORT_SYMBOL(jazz_dma_ops); diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c index 569fecd7b5b234..d4e702d74b3393 100644 --- a/arch/powerpc/kernel/dma-iommu.c +++ b/arch/powerpc/kernel/dma-iommu.c @@ -137,4 +137,6 @@ const struct dma_map_ops dma_iommu_ops = { .get_required_mask = dma_iommu_get_required_mask, .mmap = dma_common_mmap, .get_sgtable = dma_common_get_sgtable, + .alloc_pages = dma_common_alloc_pages, + .free_pages = dma_common_free_pages, }; diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/syst...

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

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