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

[Vivian Wang]

On 4/25/26 10:02, Guo Ren wrote:
>> 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@xxxxxxxxxxx>
>> ---
>> 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@xxxxxxxxxx/

Sorry for the trouble, it seems that some miscommunication has occurred.
While I was able to reproduce this problem in an emulator, I do not have
access to this hardware and had misunderstood the context and the nature
of this platform.

Please consider this patch abandoned.

With apologies,
Vivian "dramforever" Wang