From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0852614F70 for ; Sat, 25 Apr 2026 02:03:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777082582; cv=none; b=AFwgvsF3QpynoZJR12CIVq8tjTaCzKUpruY5Giis/DvfHULzQuNv2WHTRoGGE9Hp0q9SoatXBqwYYAoFxjr3Bwh+fo/j4bueWpnN8P7/Yo2c9SNqOGk3+2G2jpYmuN5gS2Rzarwzsk9uxUJmy+8MM84LIpFAQ1noA+yXYwW5Rkw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777082582; c=relaxed/simple; bh=A45K/CWK8n0nOi0K0sJmVboJfyVuvgSAW7/u0eXkmN4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PFJn7Z6WiGlPW4t+34hMwplpctl58ChQj/PUQzFnJXhuscN9vIef1XGZLzWJ6hia/XBwenKCblmHDg8KFuUkHcqGvaUfY2+MM89PbKsLxIdJ/UT2tsWcESsPBhRZ6TS8BfpbHnl4yUCiiisOKBDKgQlFiC2CWhjVQbxcb753nuQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FDfpxbcq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FDfpxbcq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 115C3C19425; Sat, 25 Apr 2026 02:02:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777082581; bh=A45K/CWK8n0nOi0K0sJmVboJfyVuvgSAW7/u0eXkmN4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FDfpxbcqUp79tafLBYbvroiHXf20yajaf9RY5wjHdgFt7C9zegzNcLwKzxoYYniGR BJWjDcdhdZGq1vYEhhkBzNlrYn3rrGGFbd7JaiY+65rB8HgUzeRz/8WlHeRaqII3Em sBwjZbKgIPM6zeck0MnGc6qswtaRPR1k7oPrvu84nyGnRWrkL768K1bSRxRxin256U CR+rGUOvJmcuYyL1Z8+OHb4GHtv/8sqvaEf05a6wwzjdMlEddsY3FDGv6gFJ8H6SFr TuIK5jWZHjMomXQU1Zurgx+/bw0X5BY3gbXpcWLnsxTH6Bfkr+c/6gGeP6Ub7rbbWj j3wUsKWN57f/Q== From: Guo Ren To: wangruikang@iscas.ac.cn Cc: alex@ghiti.fr, gaohan@iscas.ac.cn, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, palmer@dabbelt.com, pjw@kernel.org Subject: Re: [PATCH] riscv: mm: Do not probe satp mode limit if known in FDT Date: Sat, 25 Apr 2026 02:02:51 +0000 Message-ID: <20260425020253.3323599-1-guoren@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260424-riscv-mm-trust-fdt-mmu-type-v1-1-57f3313275d2@iscas.ac.cn> References: <20260424-riscv-mm-trust-fdt-mmu-type-v1-1-57f3313275d2@iscas.ac.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit > 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 > --- > 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