[PATCH] riscv: mm: Do not probe satp mode limit if known in FDT

[Guo Ren]

> Some systems may only have memory at such a high address that an
> identity mapping cannot be made in Sv48, or even Sv57. To avoid crashing
> while probing satp mode support, trust the mmu-type property from FDT
> and avoid probing if it is set.
> 
> For example, if a CPU supports (up to) Sv57 but the SoC it is on only
> has memory starting at 128 TiB, an identity mapping cannot be made in
> Sv48. If the user specifies "no5lvl" on the command line,
> set_satp_mode() will attempt to test Sv48 support and crash, since the
> virtual address is too high. Instead, given the correct FDT CPU node
> property mmu-type = "riscv,sv57", set_satp_mode() can pick the maximum
> allowed mode from command line and FDT, namely Sv48, without probing.
> 
> Handling of mmu-type "riscv,sv57" in set_satp_mode_from_fdt() is added
> since it is now needed.
> 
> Signed-off-by: Vivian Wang <wangruikang at iscas.ac.cn>
> ---
> Tested on QEMU 10.2.2 on all 3*3 combinations of Sv39/Sv48/Sv57 and
> (none)/no4lvl/no5lvl.
> 
> In theory this could be a break if mmu-type is wrong, but so many other
> things would break if the FDT is wrong anyway.
> 
> Also note that this doesn't apply on ACPI since it is difficult to use
> ACPICA and read ACPI RHCT at this point, so that will just fall back to
> probing. Hopefully UEFI/ACPI + this atrocious SoC design never happens,
> since the high memory base address would prevent a lot of PCI(e) devices
> from working without an IOMMU. (Fingers crossed.)

Missing UEFI/ACPI is incorrect. RISC-V servers standardize on UEFI+ACPI.
We should support RHCT parsing instead of hoping high-memory ACPI systems
“never happen”.

Calling the high-memory SoC design “atrocious” is technically wrong and
concerning. The RISC-V spec explicitly allows DRAM at any physical address
(e.g. 128 TiB). With TB/PB-scale memory on the horizon, this is a valid SoC
choice.

This patch does not solve the problem at its root. The core issue is that
we are passing an invalid virtual address (VA) as input to satp mode
probing. Strengthening the VA check on the input side would fix it cleanly.

I already posted the fix for this exact issue three months ago: [1].
This should address both DT and UEFI/ACPI scenarios.

[1]: https://lore.kernel.org/linux-riscv/20260125055212.433163-1-guoren@kernel.org/

Best Regards
  GUO Ren