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

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

Adding Brendan to this thread.

Will,

Looks like you dropped me from your reply.

On Tue, 22 Sep 2026 at 15:55:59 +0100, Will Deacon wrote:
>On Tue, Sep 22, 2026 at 11:27:10AM +0530, Sumit Garg wrote:
>> On Mon, 21 Sep 2026 at 12:00:42 +0100, Vincent Donnefort wrote:
>> > This series is a follow-up to the discussion that has started here [1].
>> >
>> > When memory is lent to the Secure world via FF-A, CPU speculative
>> > accesses from NS to the lent pages can still occur as long as it retains
>> > a cacheable mapping to it.
>> >
>> > Ideally, lent memory would be "no-map" but that would mean giving up
>> > MiBs of useful memory, so let's try to do better with the help of a CMA
>> > pool.
>> >
>> > On arm64, modifying the direct map at runtime is generally restricted
>> > because the linear map defaults to block mapping and splitting blocks at
>> > runtime may trigger fatal page fault, unless the CPU implements BBML3
>> > or the entire direct map was mapped at page granularity from boot.
>> > Forcing last-level mappings system-wide incurs a severe penalty we want
>> > to avoid. Instead, this series introduces targeted last-level mappings
>> > for designated memory regions, along with the "arm,ffa-lend-pool" CMA
>> > driver to manage unmapping and remapping on lend/reclaim transitions:
>> >
>> > 1. memblock:
>> >   - Introduce MEMBLOCK_PTEMAP to force PTE mappings only for a specific region.
>> >
>> > 2. set_memory infrastructure:
>> >   - Introduce can_set_direct_map_range() to check if a specific address
>> >     range is mapped with last-level entries and can be modified safely.
>> >   - Introduce __set_direct_map_*() variants that bypass redundant checks
>> >     when the caller has already validated the range.
>> >
>> > 3. "arm,ffa-lend-pool" driver
>> >   - Introduce the "arm,ffa-lend-pool" CMA reserved-memory driver, which
>> >     unmaps pages prior to lending (ffa_prepare_lend()) and restores them
>> >     when reclaimed (ffa_lend_reclaimed()).
>> >
>> > 4. Optee support
>> >   - Hook OP-TEE dynamic protected memory pools to "arm,ffa-lend-pool" for
>> >     both SMC (via DT memory-region phandle) and FF-A (via
>> >     ffa_lend_pool_attach()) transports.
>>
>>
>> Thanks for your proposal in trying to solve this hard problem of
>> unmapping pages from kernel linear map. I remember discussing this
>> problem last year at LPC too.
>>
>> Have you had a chance to look at a more generic MM proposal around this
>> issue here [1]?
>>
>> One of the major concern for me with your proposal is tying the
>> protected memory allocation to fixed sized platform specific pool size
>> based on DT. Then the cost of granular mappings/unmapping if the
>> platforms choose to enlarge these pools.
>>
>> As you maybe aware one of the major use-cases here for protected DMAbufs
>> is the secure media pipeline use-case which is memory intensive
>> workload. IMO, the solution proposed at [1] seems to address it although
>> people have flagged rough edges there but should be addressable.
>>
>> Can you try a port of [1] for arm64 since the author did all the work
>> with x86 as reference?
>>
>> [1] https://lore.kernel.org/all/20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com/
>
>I spoke to Brendan at LPC (?) last year but this doesn't really work
>for arm64 because it relies on being able to unmap arbitrary parts of
>the linear map, which isn't generally possible unless you force pte-level
>mappings for everything, which is prohibitive for perf/power.

As per the cover letter it's about allocating pages that are not present
in the direct map. This essentially fits the protected DMABufs use-case
where we don't want any kernel mapping to exist at any time. Bufers
allocated from protected DMABufs are only meant to be accessed by the
TEE implementation or HW accelerators like in the secure media pipeline.

>
>Vincent's series tackles that by using a pool so that only that part of
>memory requires the pte-level mappings in the linear map. That's the
>whole point of it, so I don't think it makes sense to drop it in favour
>of Brendan's approach (which doesn't work).
>

For protected DMABufs, we even don't require any pte-level mappings in
linear map. The whole idea of mapping and unmapping is just a bottleneck
for performance sensitive secure media pipeline use-cases. That's why if
we can support __GFP_UNMAPPED with the memory allocator on arm64 would
be the best fit for this use-case.

Now the question is why arm64 can't support __GFP_UNMAPPED similar to
how Brendan is doing it for x86?

-Sumit