On Fri, Aug 21, 2026 at 09:44:49PM +0100, Vincent Donnefort wrote: > [...] > > > > > Interesting. I had been thinking more along the lines of adding this > > > > directly into memblock using a new entry in enum memblock_flags. None of > > > > the existing ones seem to do what we need here, though some are closely > > > > related. MEMBLOCK_SECURE or MEMBLOCK_PROTECTED are quite specific and > > > > don't necessarily mean that we need the mapping to be page-granular, so > > > > MEMBLOCK_PAGE_GRANULAR is perhaps clearer. > > > > > > I thought it would be interesting to not have to modify memblock since it > > > is > > > used for all architectures, while the DT is at least slightly less > > > widespread. > > > > This isn't something that is DT specific. On the Tegra side, I suspect > > we might need this on ACPI platforms eventually, too. And it's not an > > ARM specific feature either. Other platforms could use shared carveouts, > > too. > > Agreed, and actually I have tried the memblock version and it looks quite > neat! > > I will share what I have after the merge-window. > > > > > > Also, cma_init_reserved_mem() could use an order 9. In that case > > > PTE-level isn't > > > necessary and we could just use PMD-level. Extending that support would > > > be more > > > cumbersome with a memblock flag than with a callback. > > > > > > rmem_cma_setup() hardcoding an order 0, perhaps this isn't really a > > > problem at > > > the moment? > > > > How so? memblock is really just used as a way of backing the CMA. How > > CMA subdivides it doesn't really matter, right? > > > > Or are you suggesting that if we use an entire PMD as granularity, we > > could equally well remove the entire PMD from the linear mapping instead > > of doing it page-by-page? I think that'd work really well for at least > > VPR, since it is 1 MiB aligned anyway. Using a granularity of 2 MiB is > > easily doable. > > Yes, that is what I meant. We could easily force a PMD-level mapping instead > of > PTE-level one. But then that means declaring another memblock flag. > > > > > For anything that doesn't require a single contiguous area to be > > protected this might be a bit more challenging since it potentially > > wastes a lot of memory. On the other hand, a lot of this is heavily > > custom code anyway, so the entire stack could be modified to make > > efficient use of this (i.e. userspace could allocate a larger chunk > > for a pool of buffers, etc.). > > > > > But yeah, the alternative is to create a "memblock_mark_forcepte" (it > > > seems > > > memblock_setclr_flag does split memblocks) and let of_reserved_mem call > > > that > > > function. Finally the arm64 mmu code can simply check for the flag before > > > calling __map_memblock. Perhaps it isn't that bad in the end? > > > > It sounds like the right level of abstraction to me. But I'm not too > > familiar with this code, so it'd be good to hear from the MM and/or ARM > > maintainers what they think about this. > > > > [...] > > > I had in mind to extend "shared-dma-pool" to handle > > > set_direct_map_invalid_noflush()/set_direct_map_default_noflush() based > > > on an > > > option. But perhaps it is better to create another separate driver. And > > > VPR > > > needing a specific dma-heap driver anyway, it could call the direct-map > > > functions there too without relying on CMA to do anything? > > > > I think it'd be nice to have separate APIs for this case where we know > > the memory region is already page-granular (or, I suppose, PMD granular) > > and removing from (or adding back to) the linear mapping is safe. That > > way we could avoid the checks for can_set_direct_map() for each page. > > > > It'd also be nice to have a version that can update the protection bits > > for a range of pages (would map directly to update_range_prot()) instead > > of having to manually iterate over each page in a range. > > > > How about? > > /* True if can_set_direct_map() or [start, end) is mapped at PTE-level */ > can_set_direct_map_range(phys_addr_t start, phys_addr_t end); > > /* Must check can_set_direct_map() or can_set_direct_map_range() first */ > __set_direct_map_invalid_noflush(phys_addr_t start, phys_addr_t end) > __set_direct_map_default_noflush(phys_addr_t start, phys_addr_t end) > > > A good middle-ground might be to have helpers that do the grunt work and > > they can then be called from VPR and the shared-dma-pool drivers to have > > pages removed from the linear mapping. VPR and similar can then perform > > the hardware protection bits on top of that. > > I believe between the reserved-memory attribute to force the last-level > mappings > and the direct map functions above, there's enough for the VPR driver? > > -- > Vincent > > > > > Thierry
I have pushed a first version here [1]. I am waiting for the merge window to end before posting anything on the list, but let me know if you have any comment. [1] https://android-kvm.googlesource.com/linux/+/refs/heads/vdonnefort/ffa-lend-pool -- Vincent
