mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 v2 0/7] riscv: kexec: Fix VCPU crash on kexec/kdump under KVM
Date: Tue, 26 May 2026 20:50:02 +0800	[thread overview]
Message-ID: <20260526125009.2404-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.

v1 (Link below) addressed the crash path only. v2 extends the same
mechanism to the normal kexec path (kexec -l/-e) and reworks the
trampoline as a shared piece of infrastructure between the two paths.

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 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 v2:
    - Extend the trampoline mechanism to the normal kexec path; the
      legacy stvec trick in riscv_kexec_relocate (csrw satp,0 followed
      by jr s6 to land at PA) is replaced by a small wrapper
      riscv_kexec_relocate_entry in .kexec.tramp.text that performs
      the same two-step transition used by the crash path and then
      hands off to the PA of control_code_buffer.   
    - Page-align both ends of the .kexec.tramp.text section so no
      .rodata neighbour can leak into the identity-mapped executable
      trampoline page, and assert the section fits within one page.
    - In machine_kexec() pin t3 = 0 and the call arguments (a0..a4)
      to their ABI registers via local register asm variables and
      perform the final jr inside the inline asm block, so the
      compiler can never insert a scratch use of t3 between the
      argument setup and the trampoline entry. The bare
      "asm volatile ("li t3, 0" ::: "t3")" placebo used in v1 is
      not actually a guarantee.
    - Link to v1:
      https://lore.kernel.org/linux-riscv/20260324114527.91494-1-fangyu.yu@linux.alibaba.com/

Fangyu Yu (7):
  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/image-vars.h     |  14 ++++
 arch/riscv/kernel/kexec_relocate.S |  97 +++++++++++++++++------
 arch/riscv/kernel/machine_kexec.c  | 123 +++++++++++++++++++++++++++--
 arch/riscv/kernel/vmlinux.lds.S    |   1 +
 5 files changed, 209 insertions(+), 31 deletions(-)

-- 
2.50.1


             reply	other threads:[~2026-05-26 12:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26 12:50 fangyu.yu [this message]
2026-05-26 12:50 ` [PATCH v2 1/7] riscv: Add kexec trampoline text section to vmlinux.lds.S fangyu.yu
2026-05-26 12:50 ` [PATCH v2 2/7] riscv: kexec: Place norelocate trampoline into .kexec.tramp.text fangyu.yu
2026-05-26 12:50 ` [PATCH v2 3/7] riscv: kexec: Build trampoline page tables for crash kernel entry fangyu.yu
2026-05-26 12:50 ` [PATCH v2 4/7] riscv: kexec: Switch to trampoline page table before norelocate fangyu.yu
2026-05-26 12:50 ` [PATCH v2 5/7] riscv: kexec: Always build the trampoline page table fangyu.yu
2026-05-26 12:50 ` [PATCH v2 6/7] riscv: kexec: Add the relocate-trampoline wrapper fangyu.yu
2026-05-26 12:50 ` [PATCH v2 7/7] 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=20260526125009.2404-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®