mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chen Pei <cp0613@linux.alibaba.com>
To: pjw@kernel.org, palmer@dabbelt.com, alex@ghiti.fr,
	rppt@kernel.org, pasha.tatashin@soleen.com, pratyush@kernel.org,
	graf@amazon.com, shuah@kernel.org
Cc: guoren@kernel.org, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, kexec@lists.infradead.org
Subject: [PATCH v2 0/5] riscv: Enable kexec handover and live update
Date: Tue,  3 Nov 2026 16:09:21 +0800	[thread overview]
Message-ID: <20261103080926.2079-1-cp0613@linux.alibaba.com> (raw)

Host kernel updates in the cloud should not require draining the
machine: next to live migration to another host, replacing the kernel
in place while preserving selected workload state ("live update") is
what KHO/LUO were built for, and LUO's documentation names hypervisor
hosts as its primary use case. This series closes the gap for riscv64
and validates it with both upstream test runners.

KHO has been architecture independent since it was merged: the outgoing
kernel publishes the handover FDT and the scratch descriptor array in
the /chosen node of the DTB it builds for the incoming kernel, and the
incoming kernel collects both while scanning that node -- which is why
the arm64 integration (commit 274cdcb1c004) needed only three lines of
arch code.

Patch 1 is generic and comes first because enabling KHO on riscv64 needs
it: is_kho_boot() runs the handover FDT address through phys_to_virt()
only to return a boolean, and on riscv64 that is a BUG() before the
linear map offset exists. Neither caller dereferences the value, so
testing the physical address is enough.

RISC-V otherwise already walks the generic paths (load_extra_segments()
-> of_kexec_alloc_and_setup_fdt(), parse_dtb() ->
early_init_dt_scan()). The remaining blocker is ordering: setup_arch()
runs early_ioremap_setup() *after* parse_dtb(), so kho_populate()'s
early_memremap() of the handover FDT returns "offset + 0" -- NULL for a
page aligned address -- and the handover is dropped:

  KHO: setup: failed to memremap FDT (0x810bb000)
  KHO: disabling KHO revival

Patch 2 fixes that ordering, matching arm64/x86 and standing on its own
regardless of KHO. Patch 3 enables ARCH_SUPPORTS_KEXEC_HANDOVER as
"def_bool 64BIT && MMU" rather than arm64's "def_bool y":
ARCH_SUPPORTS_KEXEC_FILE is already 64BIT-only, and KEXEC_HANDOVER
selects CMA, which depends on MMU. Patches 4 and 5 teach the two
upstream vmtest runners about riscv64. LIVEUPDATE depends only on
KEXEC_HANDOVER, so patch 3 makes it selectable on riscv as well.

No DT schema changes are needed: linux,kho-fdt / linux,kho-scratch are
the properties arm64 introduced (commit 274cdcb1c004), and their
binding lives in the external dt-schema repository [1] rather than in
Documentation.

[1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/chosen.yaml

Changes since v1:
 - New patch 1: kho: Do not translate the handover FDT address in
   is_kho_boot(), a generic fix the riscv enablement needs.
 - Rebased onto linux-next-20261102 (2637bdec0535).

Test
----
Testing on linux-next-20261102 (2637bdec0535) with qemu-system-riscv64
(virt, -cpu max, TCG); method and logs under the --- of patches 1, 4
and 5:
  - patch 1, UEFI handover boot (edk2 on pflash over OpenSBI
    fw_dynamic, DEBUG_VIRTUAL=y): a BUG_ON in the incoming kernel on the
    first handover without the patch, 29 consecutive handovers with it
  - the same two kernels handing over from a device tree boot instead:
    both succeed, so what fails is the UEFI path and not the handover
  - kho vmtest: "ok 1 KHO succeeded"
  - liveupdate vmtest, all four suites passed one by one (simple,
    multi-session, 500 files, 2000 sessions)
  - riscv defconfig with and without CONFIG_KEXEC_HANDOVER both boot to
    userspace with no oops on the console; builds: riscv defconfig
    (+KHO), rv32_defconfig, arm64 defconfig (+KHO), x86_64 defconfig
    (+KHO)

Additionally, a workload-continuity test was run outside the selftests:
a counter process was snapshot with criu 4.3, the dump was carried
across the kexec in an LUO-preserved memfd, and criu restored it in the
new kernel. The process resumed with the same PID and open log file and
kept counting from where it was dumped (500006 -> 500007, no lost or
duplicated ticks).

Chen Pei (5):
  kho: Do not translate the handover FDT address in is_kho_boot()
  riscv: Call early_ioremap_setup() before parsing the DTB
  riscv: Add support for kexec handover (KHO)
  selftests: kho: Add riscv support
  selftests: liveupdate: Add riscv support

 arch/riscv/Kconfig                                | 3 +++
 arch/riscv/kernel/setup.c                         | 2 +-
 kernel/liveupdate/kexec_handover.c                | 2 +-
 tools/testing/selftests/kho/riscv.conf            | 9 +++++++++
 tools/testing/selftests/kho/vmtest.sh             | 3 ++-
 tools/testing/selftests/liveupdate/config.riscv64 | 3 +++
 tools/testing/selftests/liveupdate/run-vmtests.sh | 2 +-
 tools/testing/selftests/liveupdate/vmtest.sh      | 8 +++++++-
 8 files changed, 27 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/kho/riscv.conf
 create mode 100644 tools/testing/selftests/liveupdate/config.riscv64


base-commit: 2637bdec0535a2044cd830eba9a79363651d9043
-- 
2.50.1


             reply	other threads:[~2026-11-03  8:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03  8:09 Chen Pei [this message]
2026-11-03  8:09 ` [PATCH v2 1/5] kho: Do not translate the handover FDT address in is_kho_boot() Chen Pei
2026-11-03  8:09 ` [PATCH v2 2/5] riscv: Call early_ioremap_setup() before parsing the DTB Chen Pei
2026-11-03  8:09 ` [PATCH v2 3/5] riscv: Add support for kexec handover (KHO) Chen Pei
2026-11-03  8:09 ` [PATCH v2 4/5] selftests: kho: Add riscv support Chen Pei
2026-11-03  8:09 ` [PATCH v2 5/5] selftests: liveupdate: " Chen Pei

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=20261103080926.2079-1-cp0613@linux.alibaba.com \
    --to=cp0613@linux.alibaba.com \
    --cc=alex@ghiti.fr \
    --cc=graf@amazon.com \
    --cc=guoren@kernel.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pjw@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    /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®