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 0/9] riscv: kexec: Make kexec/kdump robust under VS-mode
Date: Thu, 4 Jun 2026 21:24:09 +0800 [thread overview]
Message-ID: <20260604132418.15725-1-fangyu.yu@linux.alibaba.com> (raw)
From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
In a RISC-V kernel, both kexec and crashdump need to hand off execution
to the next kernel after tearing down the current kernel address space.
However, under virtualization the guest uses two-stage address
translation, and pc does not jump to stvec after setting satp to zero,
so the legacy single-step "csrw satp,0 + stvec redirect" sequence
traps with "kvm run failed Operation not supported" and the VCPU dies.
This patch set introduces a dedicated kexec trampoline text section and
builds a minimal trampoline page table for it. Both handoffs are then
reworked into a two-pass trampoline:
1. First enter via the kernel VA, install the trampoline page table,
and jump to the trampoline VA(=PA) of the entry stub;
2. Continue execution with PC already on a PA, drop SATP with
csrw satp,0 (now safe because PC re-anchoring is moot), and
jump directly to the target -- either the crash kernel entry
(crash path) or the per-image control_code_buffer that runs
the relocate body with SATP=0 throughout (normal path).
With this, both kexec and crashdump in RISC-V guests become robust
against the two-stage translation.
Tested on QEMU virt under two configurations:
* HS-mode bare (QEMU TCG) -- regression check
- normal kexec: kexec -l/-e succeeds, second kernel boots and
prints the userspace SECOND BOOT marker.
- crash kdump: panic triggers crash kernel boot, /proc/vmcore
opens cleanly in crash(1) and shows the panic
backtrace.
* VS-mode (L0 x86 + QEMU TCG -> L1 riscv64 + KVM -> L2)
Before this series, both paths die with
kvm run failed Operation not supported
and an all-zero M-mode register dump on the SATP transition.
After this series, both paths succeed end-to-end and the
vmcore opens cleanly in crash.
---
Changes in v3 (Sashiko AI review):
- Add two new Fixes: patches at the start of the series:
#1: machine_kexec_cleanup() was empty, so the set_memory_x()
call in prepare() leaked an executable direct-map page back
to the buddy allocator on kexec -u (W^X bypass). Fix: add
set_memory_nx() in cleanup.
#2: machine_kexec_prepare() FDT search checked
memsz <= sizeof(fdt) but read sizeof(fdt) bytes from
segment[i].buf, which can be smaller than memsz. Fix: check
bufsz instead.
- Inline the .kexec.tramp.text section definition directly into
vmlinux.lds.S instead of using a macro in image-vars.h.
- Rewrite map_tramp_page() to share a single set of lower-level
page tables between the VA and PA mappings (5 BSS pages instead
of 9), with a collision-safe walker that only populates entries
still zero. Add Sv32 support.
- Link to v2:
https://lore.kernel.org/linux-riscv/20260526125009.2404-1-fangyu.yu@linux.alibaba.com/
- Link to v1:
https://lore.kernel.org/linux-riscv/20260324114527.91494-1-fangyu.yu@linux.alibaba.com/
Fangyu Yu (9):
riscv: kexec: Reset executable bit on the control code page in cleanup
riscv: kexec: Bound FDT search by source buffer size, not destination
riscv: Add kexec trampoline text section to vmlinux.lds.S
riscv: kexec: Place norelocate trampoline into .kexec.tramp.text
riscv: kexec: Build trampoline page tables for crash kernel entry
riscv: kexec: Switch to trampoline page table before norelocate
riscv: kexec: Always build the trampoline page table
riscv: kexec: Add the relocate-trampoline wrapper
riscv: kexec: Route normal kexec through the trampoline page table
arch/riscv/include/asm/kexec.h | 5 +
arch/riscv/kernel/kexec_relocate.S | 92 +++++++++++-----
arch/riscv/kernel/machine_kexec.c | 171 +++++++++++++++++++++++++++--
arch/riscv/kernel/vmlinux.lds.S | 10 ++
4 files changed, 241 insertions(+), 37 deletions(-)
--
2.50.1
next 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 fangyu.yu [this message]
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 ` [PATCH v3 9/9] riscv: kexec: Route normal kexec through the trampoline page table fangyu.yu
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-1-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®