mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] riscv: kexec_file: Constrain segment placement to direct map
@ 2026-05-19 17:06 Han Gao
  2026-05-21 22:14 ` Paul Walmsley
  0 siblings, 1 reply; 2+ messages in thread
From: Han Gao @ 2026-05-19 17:06 UTC (permalink / raw)
  To: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Song Shuai, Björn Töpel, Breno Leitao, Kees Cook,
	Han Gao
  Cc: linux-riscv, linux-kernel, Han Gao

When kexec_file_load places segments with buf_max=ULONG_MAX and
top_down=true, they land at the highest available physical addresses.
On RISC-V the size of the linear mapping is determined by the active
VM mode: SV39 caps the direct map at roughly 128GB, while SV48/SV57
extend the range substantially further. When the installed physical
memory exceeds the direct map size of the active mode, top-down
placement puts DTB/initrd at physical addresses outside the linearly
mapped region. The kexec'd kernel cannot reach them during early
boot, triggering a page fault at memcmp in start_kernel.

Fix by constraining buf_max to PFN_PHYS(max_low_pfn), which reflects
the runtime direct map boundary for the active VM mode (SV39/SV48/
SV57). This keeps all kexec segments within the linearly mapped
region while preserving the upstream top_down allocation strategy.

Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
---
 arch/riscv/kernel/machine_kexec_file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 54e2d9552e93..59d4bbc848a8 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -13,6 +13,7 @@
 #include <linux/libfdt.h>
 #include <linux/types.h>
 #include <linux/memblock.h>
+#include <linux/pfn.h>
 #include <linux/vmalloc.h>
 #include <asm/setup.h>
 #include <asm/insn.h>
@@ -266,7 +267,7 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,
 
 	kbuf.image = image;
 	kbuf.buf_min = kernel_start + kernel_len;
-	kbuf.buf_max = ULONG_MAX;
+	kbuf.buf_max = PFN_PHYS(max_low_pfn);
 
 #ifdef CONFIG_CRASH_DUMP
 	/* Add elfcorehdr */
-- 
2.47.3


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] riscv: kexec_file: Constrain segment placement to direct map
  2026-05-19 17:06 [PATCH] riscv: kexec_file: Constrain segment placement to direct map Han Gao
@ 2026-05-21 22:14 ` Paul Walmsley
  0 siblings, 0 replies; 2+ messages in thread
From: Paul Walmsley @ 2026-05-21 22:14 UTC (permalink / raw)
  To: Han Gao
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Song Shuai, Björn Töpel, Breno Leitao, Kees Cook,
	linux-riscv, linux-kernel, Han Gao

On Wed, 20 May 2026, Han Gao wrote:

> When kexec_file_load places segments with buf_max=ULONG_MAX and
> top_down=true, they land at the highest available physical addresses.
> On RISC-V the size of the linear mapping is determined by the active
> VM mode: SV39 caps the direct map at roughly 128GB, while SV48/SV57
> extend the range substantially further. When the installed physical
> memory exceeds the direct map size of the active mode, top-down
> placement puts DTB/initrd at physical addresses outside the linearly
> mapped region. The kexec'd kernel cannot reach them during early
> boot, triggering a page fault at memcmp in start_kernel.
> 
> Fix by constraining buf_max to PFN_PHYS(max_low_pfn), which reflects
> the runtime direct map boundary for the active VM mode (SV39/SV48/
> SV57). This keeps all kexec segments within the linearly mapped
> region while preserving the upstream top_down allocation strategy.
> 
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>

Thanks, queued for v7.1-rc.


- Paul

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-05-21 22:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-05-19 17:06 [PATCH] riscv: kexec_file: Constrain segment placement to direct map Han Gao
2026-05-21 22:14 ` Paul Walmsley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome