On Fri, Jul 03, 2026 at 06:13:31PM +0100, Will Deacon wrote:
On Thu, Jul 02, 2026 at 06:41:23PM +0200, Thierry Reding wrote:
On Thu, Jul 02, 2026 at 03:46:44PM +0200, Thierry Reding wrote:
On Thu, Jul 02, 2026 at 10:18:47AM +0100, Will Deacon wrote:
On Wed, Jul 01, 2026 at 06:08:15PM +0200, Thierry Reding wrote:
From: Chun Ng chunn@nvidia.com
Add helpers to swap PROT_NORMAL and PROT_DEVICE_nGnRnE protection bits on a kernel-linear-map range.
That sounds like a really terrible idea. Why is this necessary and how does it interact with things like load_unaligned_zeropad()?
This is necessary because once the memory controller has walled off the new memory region the CPU must not access it under any circumstances or it'll cause the CPU to lock up (I think technically it'll hit an SError but in practice that just means it'll freeze, as far as I can tell).
Probably doesn't interact well at all with load_unaligned_zeropad().
I think you should unmap the memory from the linear map and memremap() it instead.
Given that the memory can never be accessed by the CPU after the memory controller locks it down, I don't think we'll even need memremap(). The only thing we really need is the sg_table we hand out via the DMA BUFs so that they can be used by device drivers to program their DMA engines internally.
Looking through some of the architecture code around this, shouldn't we simply be using set_memory_encrypted() and set_memory_decrypted() for this? While they might've been created for slightly other use-cases, they seem to be doing exactly what we want (i.e. remove the page range from the linear mapping and flushing it, or restoring the valid bit and standard permissions, respectively).
Ah... I guess we can't do it because we're not in a realm world and so the early checks in __set_memory_enc_dec() would return early and turn it into a no-op.
How about if I extract a common helper and provide set_memory_p() and set_memory_np() in terms of those. Those are available on x86 and PowerPC as well, so fairly standard. I suppose at that point we're closer to set_memory_valid().
Why not just call set_direct_map_invalid_noflush() + flush_tlb_kernel_range() for each page? We already have APIs for this.
The big challenge I see with any linear map manipulation, however, is that it will rely on can_set_direct_map() which likely means you need to give up some performance and/or security to make this work. Does memory become inaccesible dynamically at runtime? If not, the best bet would be to describe it as a carveout in the DT and mark it as "no-map" so we avoid mapping it in the first place.
While I got your attention a bit off-topic but still related question.
AFAIK a lot in arm64 drivers ecosystem relies on that ranges defined as "/reserved-memory" in DT are linked to devices that use that memory.
EFI/ACPI does not have a similar concept.
Given that more and more systems are using EFI/ACPI rather than DT as their boot protocol we probably need some way to define such memory carveouts in the ACPI world.
Will