On Tue, 29 Sep 2026 at 12:33:07 +0100, Will Deacon wrote:
On Sat, Sep 26, 2026 at 05:43:08PM +0530, Sumit Garg wrote:
Looks like you dropped me from your reply.
Huh, that's weird. If I hit reply-all ('g') in mutt, it moves the entire CC list to To: and drops you. I suspect the same thing happened to Thierry when he replied here:
https://lore.kernel.org/all/arJcN60nagFKXj2Q@orome/
I can't figure out why that's happening :/ I manually tried to fix the To: and Cc: lines in this message.
Thanks.
On Tue, 22 Sep 2026 at 15:55:59 +0100, Will Deacon wrote:
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.
That sounds like it should probably build on top of this series, then.
The main problem I see with this series is it tries to move from the generic CMA allocator to a reserved FF-A CMA pool which again comes from the DT. We already support reserved pool allocations via "no-map" which are discovered dynamically from OP-TEE.
If we can rather support a generic CMA like allocator for arm64 which can support unmapped allocations then I am all for it. These platform specific reserved pools isn't a scalable solution.
You could allocate the DMABufs from a CMA region that has no linear alias.
Allocation from generic CMA pool is already the case here:
tee_shm_alloc_dma_mem() -> dma_alloc_pages()
Do you mean it's just fine to unmap buffers allocated from generic CMA region since it doesn't have any linear alias?
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.
The point is that you will require pte-level mappings for the linear map if you want to unmap from it at runtime on arm64. If you don't, then you can end up needing to split a block mapping (e.g. pmd-level) when you decide to unmap only part of it and there isn't a safe way to do that on arm64 without transiently unmapping the entire block, which can lead to fatal translation faults during that window.
I agree with you here, what I am rather trying to find if on arm64 there is any possibilty to have a generic allocator for unmapped pages. That's the use-case here as well as what Brendan't patch-set was trying to address.
Now the question is why arm64 can't support __GFP_UNMAPPED similar to how Brendan is doing it for x86?
Because arm64 != x86? Presumably x86 doesn't have the strict break-before-make requirements we have on arm64.
Sure, sounds like you are eluding to that the generic MM flag __GFP_UNMAPPED being proposed can't be supported on arm64, right?
-Sumit