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

[Sumit Garg <sumit.garg@kernel.org>]

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@kernel.org/
>> >
>> > --
>> > 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