From: fangyu.yu@linux.alibaba.com
To: Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>, Anup Patel <anup@brainfault.org>,
Atish Patra <atishp@atishpatra.org>,
Nick Kossifidis <mick@ics.forth.gr>
Cc: "Song Shuai" <songshuaishuai@tinylab.org>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Richard Lyu" <richard.lyu@suse.com>,
"Nam Cao" <namcao@linutronix.de>,
"Jisheng Zhang" <jszhang@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
guoren@kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
kvm-riscv@lists.infradead.org, kvm@vger.kernel.org,
"Fangyu Yu" <fangyu.yu@linux.alibaba.com>
Subject: [PATCH v3 9/9] riscv: kexec: Route normal kexec through the trampoline page table
Date: Thu, 4 Jun 2026 21:24:18 +0800 [thread overview]
Message-ID: <20260604132418.15725-10-fangyu.yu@linux.alibaba.com> (raw)
In-Reply-To: <20260604132418.15725-1-fangyu.yu@linux.alibaba.com>
From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
riscv_kexec_relocate (copied into control_code_buffer) uses an stvec
trick to drop the MMU and land on the PA of the next loop label.
Under VS-mode KVM cannot emulate this single-step transition and the
VCPU dies with "kvm run failed Operation not supported".
Route normal kexec through riscv_kexec_relocate_entry, the trampoline
wrapper added in the previous patch. It drops SATP with PC already on
a PA, then hands off to control_code_buffer where the relocate body
runs with SATP=0.
Drop the stvec trick from the relocate body and pass first_ind_entry
as a physical address since the body now starts with SATP=0. The
".align 2" plus filler "nop" that ensured the PA of the loop top was
4-byte aligned -- required because the legacy stvec trick wrote that
PA into stvec.BASE, whose low two bits are MODE and are discarded by
the hardware -- is no longer load-bearing and is removed as well.
Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
---
arch/riscv/kernel/kexec_relocate.S | 26 ++++++--------------------
arch/riscv/kernel/machine_kexec.c | 27 +++++++++++++++++++--------
2 files changed, 25 insertions(+), 28 deletions(-)
diff --git a/arch/riscv/kernel/kexec_relocate.S b/arch/riscv/kernel/kexec_relocate.S
index 6c624560c9ac..7ffb83ea45fc 100644
--- a/arch/riscv/kernel/kexec_relocate.S
+++ b/arch/riscv/kernel/kexec_relocate.S
@@ -34,27 +34,13 @@ SYM_CODE_START(riscv_kexec_relocate)
csrw CSR_SIP, zero
/*
- * When we switch SATP.MODE to "Bare" we'll only
- * play with physical addresses. However the first time
- * we try to jump somewhere, the offset on the jump
- * will be relative to pc which will still be on VA. To
- * deal with this we set stvec to the physical address at
- * the start of the loop below so that we jump there in
- * any case.
+ * The trampoline wrapper (riscv_kexec_relocate_entry) has already
+ * dropped the MMU and handed control to us at this PA copy of the
+ * relocate code. From here on the entire loop runs with SATP=0 and
+ * every address (s0, s5, source/dest pointers) is a physical one.
*/
- la s6, 1f
- sub s6, s6, s4
- csrw CSR_STVEC, s6
-
- /*
- * With C-extension, here we get 42 Bytes and the next
- * .align directive would pad zeros here up to 44 Bytes.
- * So manually put a nop here to avoid zeros padding.
- */
- nop
/* Process entries in a loop */
-.align 2
1:
REG_L t0, 0(s0) /* t0 = *image->entry */
addi s0, s0, RISCV_SZPTR /* image->entry++ */
@@ -70,8 +56,8 @@ SYM_CODE_START(riscv_kexec_relocate)
andi t1, t0, 0x2
beqz t1, 2f
andi s0, t0, ~0x2
- csrw CSR_SATP, zero
- jr s6
+ /* MMU is already off; the entry wrapper handled the transition. */
+ j 1b
2:
/* IND_DONE entry ? -> jump to done label */
diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
index 71688c63af65..82fcb84a03ec 100644
--- a/arch/riscv/kernel/machine_kexec.c
+++ b/arch/riscv/kernel/machine_kexec.c
@@ -164,9 +164,6 @@ machine_kexec_prepare(struct kimage *image)
memcpy(control_code_buffer, riscv_kexec_relocate,
riscv_kexec_relocate_size);
- /* Mark the control page executable */
- set_memory_x((unsigned long) control_code_buffer, 1);
-
WRITE_ONCE(riscv_kexec_relocate_entry_pa,
__pa_symbol(&riscv_kexec_relocate_entry));
} else {
@@ -262,11 +259,15 @@ machine_kexec(struct kimage *image)
{
struct kimage_arch *internal = &image->arch;
unsigned long jump_addr = (unsigned long) image->start;
- unsigned long first_ind_entry = (unsigned long) &image->head;
+ /*
+ * The relocate body runs entirely with the MMU off (the wrapper
+ * drops SATP before jumping into control_code_buffer), so the very
+ * first entry must be a physical address.
+ */
+ unsigned long first_ind_entry = __pa(&image->head);
unsigned long this_cpu_id = __smp_processor_id();
unsigned long this_hart_id = cpuid_to_hartid_map(this_cpu_id);
unsigned long fdt_addr = internal->fdt_addr;
- void *control_code_buffer = page_address(image->control_code_page);
riscv_kexec_method kexec_method = NULL;
#ifdef CONFIG_SMP
@@ -274,10 +275,20 @@ machine_kexec(struct kimage *image)
"Some CPUs may be stale, kdump will be unreliable.\n");
#endif
- if (image->type != KEXEC_TYPE_CRASH)
- kexec_method = control_code_buffer;
- else
+ if (image->type != KEXEC_TYPE_CRASH) {
+ kexec_method = (riscv_kexec_method) &riscv_kexec_relocate_entry;
+ /*
+ * Publish the per-image control_code_buffer PA at dispatch
+ * time rather than in machine_kexec_prepare(). machine_kexec()
+ * only runs once the image has been fully loaded and committed
+ * as kexec_image, so the global cannot be left pointing at a
+ * page freed by a failed load.
+ */
+ WRITE_ONCE(riscv_kexec_cc_buffer_pa,
+ __pa(page_address(image->control_code_page)));
+ } else {
kexec_method = (riscv_kexec_method) &riscv_kexec_norelocate;
+ }
pr_notice("Will call new kernel at %08lx from hart id %lx\n",
jump_addr, this_hart_id);
--
2.50.1
prev parent reply other threads:[~2026-06-04 13:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 13:24 [PATCH v3 0/9] riscv: kexec: Make kexec/kdump robust under VS-mode fangyu.yu
2026-06-04 13:24 ` [PATCH v3 1/9] riscv: kexec: Reset executable bit on the control code page in cleanup fangyu.yu
2026-06-04 13:24 ` [PATCH v3 2/9] riscv: kexec: Bound FDT search by source buffer size, not destination fangyu.yu
2026-06-04 13:24 ` [PATCH v3 3/9] riscv: Add kexec trampoline text section to vmlinux.lds.S fangyu.yu
2026-06-04 13:24 ` [PATCH v3 4/9] riscv: kexec: Place norelocate trampoline into .kexec.tramp.text fangyu.yu
2026-06-04 13:24 ` [PATCH v3 5/9] riscv: kexec: Build trampoline page tables for crash kernel entry fangyu.yu
2026-06-04 13:24 ` [PATCH v3 6/9] riscv: kexec: Switch to trampoline page table before norelocate fangyu.yu
2026-06-04 13:24 ` [PATCH v3 7/9] riscv: kexec: Always build the trampoline page table fangyu.yu
2026-06-04 13:24 ` [PATCH v3 8/9] riscv: kexec: Add the relocate-trampoline wrapper fangyu.yu
2026-06-04 13:24 ` fangyu.yu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260604132418.15725-10-fangyu.yu@linux.alibaba.com \
--to=fangyu.yu@linux.alibaba.com \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=atishp@atishpatra.org \
--cc=bjorn@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=guoren@kernel.org \
--cc=jszhang@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mick@ics.forth.gr \
--cc=namcao@linutronix.de \
--cc=nathan@kernel.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=richard.lyu@suse.com \
--cc=songshuaishuai@tinylab.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®