Re: [PATCH v2 06/11] ARM: dma-mapping: Handle foreign buffers in arm_iommu_get_sgtable

From: Mikko Perttunen

Date: Mon Oct 19 2026 - 23:59:28 EST


On Tuesday, October 20, 2026 12:47 AM Robin Murphy wrote:
> On 16/10/2026 7:46 am, Mikko Perttunen wrote:
> > arm_iommu_get_sgtable can only describe buffers which came from
> > arm_iommu_alloc_attrs, and returns -ENXIO for anything else. This is
> > stricter than iommu_dma_get_sgtable(), which falls back to describing
> > the buffer as a single chunk.
> >
> > The difference shows up when a buffer is allocated for one device and
> > mapped for another, as TegraDRM does. Buffers are allocated on the
> > host1x logical device, which has no dma_configure and therefore uses
> > direct DMA ops, and are then mapped for a display controller behind the
> > SMMU.
> >
> > Add the same fallback as iommu_dma_get_sgtable().
>
> Hmm, that's not actually what it's for... :(
>
> The "fallback" is only for the case when iommu_dma_alloc() has hit the
> dma_alloc_from_pool() path, see a98d9ae937d2 ("arm64/iommu: handle
> non-remapped addresses in ->mmap and ->get_sgtable"). It was never meant
> for dipping into *other* DMA ops because the caller has erroneously
> passed the wrong device. Just like dma_mmap_attrs() and
> dma_free_attrs(), dma_get_sgtable_attrs() must match the original
> dma_alloc_attrs() call - that's a bug in TegraDRM.

Ah, indeed. That's easy to fix in TegraDRM. I think this happened
because TegraDRM has this (a bit unsavoury) use of DMA API on both the
drm device and the actual platform devices side by side.

Thanks,
Mikko

>
> Thanks,
> Robin.
>
> > Signed-off-by: Mikko Perttunen <mperttunen@xxxxxxxxxx>
> > ---
> > arch/arm/mm/dma-mapping.c | 25 +++++++++++++++++++++----
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > index d6315baeddb9..c2ec4f107808 100644
> > --- a/arch/arm/mm/dma-mapping.c
> > +++ b/arch/arm/mm/dma-mapping.c
> > @@ -1169,12 +1169,29 @@ static int arm_iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
> > {
> > unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> > struct page **pages = __iommu_get_pages(cpu_addr, attrs);
> > + struct page *page;
> > + int ret;
> >
> > - if (!pages)
> > - return -ENXIO;
> > + if (pages)
> > + return sg_alloc_table_from_pages(sgt, pages, count, 0, size,
> > + GFP_KERNEL);
> >
> > - return sg_alloc_table_from_pages(sgt, pages, count, 0, size,
> > - GFP_KERNEL);
> > + /*
> > + * The buffer was not allocated through these DMA ops. It may belong to
> > + * a device which is not behind an IOMMU at all, which can happen when a
> > + * buffer is allocated on one device and mapped for another. Describe it
> > + * as a single chunk, as iommu_dma_get_sgtable() does.
> > + */
> > + if (is_vmalloc_addr(cpu_addr))
> > + page = vmalloc_to_page(cpu_addr);
> > + else
> > + page = virt_to_page(cpu_addr);
> > +
> > + ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
> > + if (!ret)
> > + sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
> > +
> > + return ret;
> > }
> >
> > /*
> >
>
>