On Thu, Oct 01, 2026 at 06:04:06PM +0530, Sumit Garg wrote:
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.
I can't think of a way around a DT declaration. We need to know what region is PTE-level before the direct map is installed and of_reserved_mem is very handy for that purpose. And as this PTE-level mapping is costly we certainly only want to enable it for platforms that absolutely need it.
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.
What do you mean by generic CMA allocator here? An extension to shared-dma-pool? Or having the CMA automatically doing the unmap/map on cma_alloc() cma_release()?
Right now I have created an API for the unmapping/remapping part. It adds a burden on the caller, but the alternative solution is introducing post-alloc pre-dealloc callbacks in the CMA, which looked a bit overkilled to me when the users of that "ffa-pool" are only optee and the nvidia video dma-buf heap.