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

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

[Vivian Wang]

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@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.)
---
 arch/riscv/kernel/pi/fdt_early.c | 2 ++
 arch/riscv/mm/init.c             | 7 ++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/pi/fdt_early.c b/arch/riscv/kernel/pi/fdt_early.c
index a12ff8090f19..702253287560 100644
--- a/arch/riscv/kernel/pi/fdt_early.c
+++ b/arch/riscv/kernel/pi/fdt_early.c
@@ -218,6 +218,8 @@ u64 set_satp_mode_from_fdt(uintptr_t dtb_pa)
 			return SATP_MODE_39;
 		else if (!strcmp(mmu_type, "riscv,sv48"))
 			return SATP_MODE_48;
+		else if (!strcmp(mmu_type, "riscv,sv57"))
+			return SATP_MODE_57;
 		break;
 	}
 
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 811e03786c56..c37578eaddd0 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -859,8 +859,9 @@ static __init void set_satp_mode(uintptr_t dtb_pa)
 {
 	u64 identity_satp, hw_satp;
 	uintptr_t set_satp_mode_pmd = ((unsigned long)set_satp_mode) & PMD_MASK;
+	u64 satp_mode_limit_fdt = __pi_set_satp_mode_from_fdt(dtb_pa);
 	u64 satp_mode_limit = min_not_zero(__pi_set_satp_mode_from_cmdline(dtb_pa),
-					   __pi_set_satp_mode_from_fdt(dtb_pa));
+					   satp_mode_limit_fdt);
 
 	kernel_map.page_offset = PAGE_OFFSET_L5;
 
@@ -872,6 +873,10 @@ static __init void set_satp_mode(uintptr_t dtb_pa)
 		return;
 	}
 
+	/* Skip probing if max SATP mode known from FDT */
+	if (satp_mode_limit_fdt)
+		return;
+
 	create_p4d_mapping(early_p4d,
 			set_satp_mode_pmd, (uintptr_t)early_pud,
 			P4D_SIZE, PAGE_TABLE);

---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260424-riscv-mm-trust-fdt-mmu-type-c874f7628178

Best regards,
--  
Vivian "dramforever" Wang

Re: [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@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

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@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/

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

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

[Guo Ren]

> 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.

I also found this issue in QEMU. It can be easily reproduced with the
following modification:

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index a1c323e66d..8c1d92c8dd 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -100,7 +100,7 @@ static const MemMapEntry virt_memmap[] = {
     [VIRT_IMSIC_S] =      { 0x28000000, VIRT_IMSIC_MAX_SIZE },
     [VIRT_PCIE_ECAM] =    { 0x30000000,    0x10000000 },
     [VIRT_PCIE_MMIO] =    { 0x40000000,    0x40000000 },
-    [VIRT_DRAM] =         { 0x80000000,           0x0 },
+    [VIRT_DRAM] =         { 0x800000000000,           0x0 },
 };

Best Regards
  GUO Ren