Re: [PATCH v2 0/8] arm64: Unmap FF-A lent memory from direct map

[Sumit Garg]

On Fri, 06 Nov 2026 at 10:45:09 +0000, Vincent Donnefort wrote:
> [...]
>
> > > > Yeah I saw that constraint too, let's leave it for future extension
> > > > then although having this reordering dependency fixed will be ideal.
> > > >
> > > > >
> > > > > So the only case it would work would be when a reserved memory has set
> > > > > "linux,cma-default".
> > > > >
> > > >
> > > > Let's rather just turn DT based default CMA pool to support PTE-level
> > > > mapping and keep it configurable via Kconfig or cmdline or DT.
> > >
> > > If we need a DT declaration anyway, a Kconfig and a cmdline option aren't really
> > > necessary.
> >
> > Agree, it rather makes sense for DT independent generic CMA pool.
> >
> > >
> > > Also, Rob wasn't very keen on having a DT option for the reserved memory and
> > > suggested to have a compatible string instead [1]. So perhaps we could have a
> > > a separate driver that handles the unmapping.
> > >
> > > 	linux,cma {
> > > 		compatible = "shared-dma-pool", "unmap-on-alloc";
> > > 		reusable;
> > > 		linux,cma-default;
> > > 		...
> > > 	}
> > >
> > > That "unmap-on-alloc" driver sets the memblock flags and register some cma hooks
> > > (to be defined) for cma_alloc/cma_free where it unmaps/re-maps into the linear
> > > map.
> > >
> > > The nice property is optee won't need to be modified anymore. The downside is
> > > the entire pool is now mapped at PTE-level.
> >
> > Sounds reasonable to me. If folks are really worried about performance
> > with generic CMA PTE-level map then OP-TEE already supports no-map based
> > reserved carveouts for protected DMABufs too.
> >
> > -Sumit
> >
> > >
> > > [1] http://lore.kernel.org/all/20260902172436.GB1440252-robh@xxxxxxxxxx/
> > >
> > > --
> > > Vincent
>
> I have just looked deeper into and cma_alloc can't unmap automatically the
> default pool. Callers expect a valid linear mapping right after the alocation.
> dma_direct_alloc() and dma_direct_alloc_pages() zero the allocated page,
> dma_direct_alloc_no_mapping() runs cache maintenance on it, and the userspace
> available heap /dev/dma_heap/linux,cma zeroes it.
>
> Also, it isn't possible to use two compatible strings for the reserved memory.
> The registration stops at the first matching compatible string. Layering drivers
> won't work either.
>
> So while the pool can still be generic and serve as linux,cma-default:
>
>  linux,cma {
>      compatible = "unmappable-dma-pool";
>      reusable;
>      linux,cma-default;
>  }
>
> We can't escape providing an additional API to unmap/remap in the linear map.

Yeah it's fine to invoke these additional APIs post the CMA allocation
for protected DMA buffers.

-Sumit