Hi All, Renesas RZ/Five RISC-V SoC has Instruction local memory and Data local memory (ILM & DLM) mapped between region 0x30000 - 0x4FFFF. When a virtual address falls within this range, the MMU doesn't trigger a page fault; it assumes the virtual address is a physical address which can cause undesired behaviours. To avoid this the ILM/DLM memory regions are now added to the root domain region of the PMPU with permissions set to 0x0 for S/U modes so that any access to these regions gets blocked and for M-mode we grant full access (R/W/X). This prevents any users from accessing these regions by triggering an unhandled signal 11 in S/U modes. This works as expected but for applications say for example when doing mmap to this region would still succeed and later down the path when doing a read/write to this location would cause unhandled signal 11. To handle this case gracefully we might want mmap() itself to fail if the addr/offset falls in this local memory region. Tracing through the mmap call we have arch_mmap_check() if implemented by architectures this callback gets called and it can be used as a validator to make sure mmap() to the local memory region fails. (Note maybe this callback can be implemented using ALTERNATIVX() macro so that other RISC-V SoCs do nop() to this callback). This approach seems reasonable but isn't a generic approach. For other platforms with similar issues will have to go through similar implementation. Instead if we define the memory regions in the device tree that aren't to be allowed to be mmaped with this approach the implementation can be generic and can be used on other archs/platforms. Looking at the kernel code SPARC architecture (UltraSPARC T1) also has a hole in the virtual memory address space (relevant commit-id to fix this issue 8bcd17411643beb9a601e032d0cf1016909a81d3). As this VA hole “support” has been added a long time ago now, and maybe simply replicating their approach is not acceptable anymore hence the proposed approach. Is there any better approach which I am missing, any pointers comments welcome. Cheers, Prabhakar
