[PATCH v2 0/5] riscv: Enable kexec handover and live update

[PATCH v2 0/5] riscv: Enable kexec handover and live update

[Chen Pei]

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

[PATCH v2 1/5] kho: Do not translate the handover FDT address in is_kho_boot()

[Chen Pei]

is_kho_boot() only has to say whether a handover FDT was recorded, but
it asks kho_get_fdt() for one and so converts kho_in.fdt_phys with
phys_to_virt() just to throw the pointer away. Both callers use it as a
boolean and never dereference the result.

On riscv64 that conversion is not valid yet when efi_init() reaches it:
setup_vm() leaves kernel_map.va_pa_offset at 0 and setup_bootmem()
assigns it later, so a handover boot that came through UEFI panics in
linear_mapping_pa_to_va(). Only debug builds fail -- without
CONFIG_DEBUG_VIRTUAL __va() degenerates to "phys + 0" and the boolean
stays correct -- but the panic also goes unnoticed without an earlycon.

Check the physical address instead. Nothing needs the translation, and
architectures stay free to bring their linear mapping up whenever they
like.

Fixes: d6d511639185 ("kexec: introduce is_kho_boot()")
Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---

Tested on qemu-system-riscv64 (virt, -cpu max, TCG): edk2
RISCV_VIRT_CODE.fd/VARS.fd on pflash with OpenSBI fw_dynamic.bin below
it, and a GPT disk holding an ESP with grub plus the kernel and an ext4
partition as rootfs.  Kernel config is riscv defconfig plus
DEBUG_KERNEL, DEBUG_VIRTUAL, KEXEC_FILE, KEXEC_HANDOVER and the kho
selftest fragment; the outgoing kernel gets "kho=on" and the kho
selftest init does kexec_file_load() followed by reboot(RB_KEXEC).

Before, the first handover panics.  earlycon= is needed to see it: the
BUG precedes console registration, so without an earlycon the machine
goes silent right after kexec.

  KHO: found kexec handover data.
  efi: EFI v2.7 by EDK II
  kernel BUG at arch/riscv/mm/physaddr.c:47!
  epc : linear_mapping_pa_to_va+0x1c/0x1e
   ra : is_kho_boot+0x18/0x28

After, the same setup keeps handing over until the window closes, 29
consecutive boots and no BUG.

  KHO: found kexec handover data.
  KHO: exec from: 7.4.0-rc1-next-20261102-00005-gfca49e548231 (count 29)

 kernel/liveupdate/kexec_handover.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 6f1f55fe3181..6ab181de345c 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -1643,7 +1643,7 @@ EXPORT_SYMBOL_GPL(kho_restore_free);
  */
 bool is_kho_boot(void)
 {
-	return !!kho_get_fdt();
+	return kho_in.fdt_phys != 0;
 }
 EXPORT_SYMBOL_GPL(is_kho_boot);
 
-- 
2.50.1

[PATCH v2 2/5] riscv: Call early_ioremap_setup() before parsing the DTB

[Chen Pei]

early_ioremap_setup() fills in the slot_virt[] array whose entries the
return value of early_ioremap()/early_memremap() is composed from.  On
RISC-V it ran after parse_dtb(), so an early_memremap() reached from
the device tree scan returned "offset + 0" -- NULL for a page aligned
address -- and the caller could only report a mapping failure.  This
stayed latent because nothing reached from parse_dtb() asked for an
early mapping before; the DT based kexec handover parsing is the first
such caller, as kho_populate() maps the handover FDT and the scratch
descriptor array with early_memremap().

Move the call to the top of setup_arch(), which is how arm64 and x86
already order it (early_fixmap_init()/early_ioremap_init() before
setup_machine_fdt()/parse_setup_data()).  The BTMAP window is mapped
into early_pg_dir by setup_vm(), and RISC-V neither calls
early_ioremap_reset() nor defines __late_set_fixmap(), so the virtual
addresses stay identical across the switch to the final page tables
and nothing else in setup_arch() depends on the previous ordering.

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---
 arch/riscv/kernel/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index d79f99b86033..45e2ef9d32fa 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -308,12 +308,12 @@ extern void __init init_rt_signal_env(void);
 
 void __init setup_arch(char **cmdline_p)
 {
+	early_ioremap_setup();
 	parse_dtb();
 	setup_initial_init_mm(_stext, _etext, _edata, _end);
 
 	*cmdline_p = boot_command_line;
 
-	early_ioremap_setup();
 	sbi_init();
 	jump_label_init();
 	parse_early_param();
-- 
2.50.1

[PATCH v2 3/5] riscv: Add support for kexec handover (KHO)

[Chen Pei]

KHO is architecture independent: 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 (kho_add_chosen(), reached
from of_kexec_alloc_and_setup_fdt()), and the incoming kernel picks
both up while scanning that node (early_init_dt_check_kho() ->
kho_populate()).

RISC-V already builds that DTB in load_extra_segments() and passes it
to the incoming kernel in a1, so only the architecture symbol is
missing.  Depend on 64BIT to match ARCH_SUPPORTS_KEXEC_FILE, and on
MMU because KEXEC_HANDOVER selects CMA, which depends on MMU.

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---
 arch/riscv/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 435da0713243..e11463a923a3 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -1125,6 +1125,9 @@ config ARCH_SELECTS_KEXEC_FILE
 config ARCH_SUPPORTS_KEXEC_PURGATORY
 	def_bool ARCH_SUPPORTS_KEXEC_FILE
 
+config ARCH_SUPPORTS_KEXEC_HANDOVER
+	def_bool 64BIT && MMU
+
 config ARCH_SUPPORTS_CRASH_DUMP
 	def_bool y
 
-- 
2.50.1

[PATCH v2 4/5] selftests: kho: Add riscv support

[Chen Pei]

Teach the KHO vmtest runner about riscv64: map the target to ARCH
riscv and describe the QEMU virt machine, the kernel image and its
console -- a 16550A port probed from the device tree on virt, hence
the SERIAL_8250{,_CONSOLE} and SERIAL_OF_PLATFORM symbols.  Also
select CONFIG_SPARSEMEM_MANUAL: the runner requires
CONFIG_DEFERRED_STRUCT_PAGE_INIT, which depends on SPARSEMEM, while
riscv falls back to FLATMEM (no ARCH_SPARSEMEM_DEFAULT), so without
it the test would just be skipped.

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---

Test: qemu-system-riscv64 (virt, -cpu max, TCG), in-tree runner
"tools/testing/selftests/kho/vmtest.sh -t riscv64" (boots the Image
and kexec'es into the same Image).

  KHO: found kexec handover data.
  KHO: exec from: 7.4.0-rc1-next-20261102-00005-gfca49e548231 (count 1)
  test_kho: KHO restore succeeded
  ok 1 KHO succeeded
  # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0

 tools/testing/selftests/kho/riscv.conf | 9 +++++++++
 tools/testing/selftests/kho/vmtest.sh  | 3 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/kho/riscv.conf

diff --git a/tools/testing/selftests/kho/riscv.conf b/tools/testing/selftests/kho/riscv.conf
new file mode 100644
index 000000000000..ec2a46cd45d5
--- /dev/null
+++ b/tools/testing/selftests/kho/riscv.conf
@@ -0,0 +1,9 @@
+QEMU_CMD="qemu-system-riscv64 -M virt -cpu max"
+QEMU_KCONFIG="
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SPARSEMEM_MANUAL=y
+"
+KERNEL_IMAGE="Image"
+KERNEL_CMDLINE="console=ttyS0"
diff --git a/tools/testing/selftests/kho/vmtest.sh b/tools/testing/selftests/kho/vmtest.sh
index 1e86ffcc3a79..56cac6ae3cf9 100755
--- a/tools/testing/selftests/kho/vmtest.sh
+++ b/tools/testing/selftests/kho/vmtest.sh
@@ -21,7 +21,7 @@ Options:
 	-d)	path to the kernel build directory
 	-j)	number of jobs for compilation, similar to -j in make
 	-t)	run test for target_arch, requires CROSS_COMPILE set
-		supported targets: aarch64, x86_64
+		supported targets: aarch64, x86_64, riscv64
 	-h)	display this help
 EOF
 }
@@ -127,6 +127,7 @@ function target_to_arch() {
 	case $target in
 	     aarch64) echo "arm64" ;;
 	     x86_64) echo "x86" ;;
+	     riscv64) echo "riscv" ;;
 	     *) skip "architecture $target is not supported"
 	esac
 }
-- 
2.50.1

[PATCH v2 5/5] selftests: liveupdate: Add riscv support

[Chen Pei]

Teach the live update vmtest runner about riscv64: map the target to ARCH
riscv, describe the QEMU virt machine, the kernel image and its console,
and add the arch config fragment holding the three symbols needed to get
a console on the virt machine's 16550A port.

KHO is the only dependency of LIVEUPDATE (kernel/liveupdate/Kconfig), so
now that riscv has KHO the LUO tests only need the runner to stop
rejecting the architecture.

Add riscv64 to the CROSS_COMPILE auto-detection list and to the target
list of the batch runner as well, matching the existing aarch64/x86_64
entries.

Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>
---

Test: qemu-system-riscv64 (virt, -cpu max, -m 1G, -smp 2, TCG), in-tree
runner "tools/testing/selftests/liveupdate/vmtest.sh -t riscv64 -T <suite>",
all four suites:

  luo_kexec_simple:    SIMPLE KEXEC TEST PASSED
  luo_multi_session:   MULTI-SESSION KEXEC TEST PASSED
  luo_stress_files:    MANY-FILES KEXEC TEST PASSED (500 files)
  luo_stress_sessions: MANY-SESSIONS KEXEC TEST PASSED (2000 sessions)

The simple suite's serial log shows the full handover round trip:

  KHO: found kexec handover data.
  luo: Retrieved live update data, liveupdate number: 1
  KHO: exec from: 7.4.0-rc1-next-20261102-00005-gfca49e548231 (count 1)
  # [STAGE 2] Test data verified successfully.
  --- SIMPLE KEXEC TEST PASSED ---

 tools/testing/selftests/liveupdate/config.riscv64 | 3 +++
 tools/testing/selftests/liveupdate/run-vmtests.sh | 2 +-
 tools/testing/selftests/liveupdate/vmtest.sh      | 8 +++++++-
 3 files changed, 11 insertions(+), 2 deletions(-)
 create mode 100644 tools/testing/selftests/liveupdate/config.riscv64

diff --git a/tools/testing/selftests/liveupdate/config.riscv64 b/tools/testing/selftests/liveupdate/config.riscv64
new file mode 100644
index 000000000000..edbc551199b0
--- /dev/null
+++ b/tools/testing/selftests/liveupdate/config.riscv64
@@ -0,0 +1,3 @@
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
diff --git a/tools/testing/selftests/liveupdate/run-vmtests.sh b/tools/testing/selftests/liveupdate/run-vmtests.sh
index d656ce58c5a7..2e3f5f6f96b3 100755
--- a/tools/testing/selftests/liveupdate/run-vmtests.sh
+++ b/tools/testing/selftests/liveupdate/run-vmtests.sh
@@ -4,7 +4,7 @@
 SCRIPT_DIR=$(dirname "$(realpath "$0")")
 TEST_RUNNER="$SCRIPT_DIR/vmtest.sh"
 
-TARGETS=("x86_64" "aarch64")
+TARGETS=("x86_64" "aarch64" "riscv64")
 
 GREEN='\033[0;32m'
 RED='\033[0;31m'
diff --git a/tools/testing/selftests/liveupdate/vmtest.sh b/tools/testing/selftests/liveupdate/vmtest.sh
index f3fb4142c81d..e67e4613aee8 100755
--- a/tools/testing/selftests/liveupdate/vmtest.sh
+++ b/tools/testing/selftests/liveupdate/vmtest.sh
@@ -25,6 +25,10 @@ function get_arch_conf() {
 		QEMU_CMD="qemu-system-x86_64"
 		KERNEL_IMAGE="bzImage"
 		KERNEL_CMDLINE="console=ttyS0"
+	elif [[ "$arch" == "riscv" ]]; then
+		QEMU_CMD="qemu-system-riscv64 -M virt -cpu max"
+		KERNEL_IMAGE="Image"
+		KERNEL_CMDLINE="console=ttyS0"
 	else
 		echo "Unsupported architecture: $arch"
 		exit 1
@@ -37,7 +41,7 @@ $0 [-d build_dir] [-j jobs] [-t target_arch] [-T test_name] [-w workspace_dir] [
 Options:
 	-d)	path to the kernel build directory (default: .luo_test_build.<arch>)
 	-j)	number of jobs for compilation
-	-t)	run test for target_arch (aarch64, x86_64)
+	-t)	run test for target_arch (aarch64, x86_64, riscv64)
 	-T)	test name to run (default: luo_kexec_simple)
 	-w)	custom workspace directory (default: creates temp dir)
 	-k)	keep workspace directory after successful test
@@ -87,6 +91,7 @@ function detect_cross_compile() {
 	case "$target" in
 		aarch64) candidate="aarch64-linux-gnu-" ;;
 		x86_64)  candidate="x86_64-linux-gnu-" ;;
+		riscv64) candidate="riscv64-linux-gnu-" ;;
 		*)       skip "Auto-detection for target '$target' not supported. Please set CROSS_COMPILE manually." ;;
 	esac
 
@@ -194,6 +199,7 @@ function target_to_arch() {
 	case $target in
 	     aarch64) echo "arm64" ;;
 	     x86_64) echo "x86" ;;
+	     riscv64) echo "riscv" ;;
 	     *) skip "architecture $target is not supported"
 	esac
 }
-- 
2.50.1

Re: [PATCH v2 1/5] kho: Do not translate the handover FDT address in is_kho_boot()

[sashiko-bot]

> is_kho_boot() only has to say whether a handover FDT was recorded, but
> it asks kho_get_fdt() for one and so converts kho_in.fdt_phys with
> phys_to_virt() just to throw the pointer away. Both callers use it as a
> boolean and never dereference the result.
> 
> On riscv64 that conversion is not valid yet when efi_init() reaches it:
> setup_vm() leaves kernel_map.va_pa_offset at 0 and setup_bootmem()
> assigns it later, so a handover boot that came through UEFI panics in
> linear_mapping_pa_to_va(). Only debug builds fail -- without
> CONFIG_DEBUG_VIRTUAL __va() degenerates to "phys + 0" and the boolean
> stays correct -- but the panic also goes unnoticed without an earlycon.
> 
> Check the physical address instead. Nothing needs the translation, and
> architectures stay free to bring their linear mapping up whenever they
> like.
> 
> Fixes: d6d511639185 ("kexec: introduce is_kho_boot()")
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103080926.2079-1-cp0613@linux.alibaba.com?part=1

Re: [PATCH v2 2/5] riscv: Call early_ioremap_setup() before parsing the DTB

[sashiko-bot]

> early_ioremap_setup() fills in the slot_virt[] array whose entries the
> return value of early_ioremap()/early_memremap() is composed from.  On
> RISC-V it ran after parse_dtb(), so an early_memremap() reached from
> the device tree scan returned "offset + 0" -- NULL for a page aligned
> address -- and the caller could only report a mapping failure.  This
> stayed latent because nothing reached from parse_dtb() asked for an
> early mapping before; the DT based kexec handover parsing is the first
> such caller, as kho_populate() maps the handover FDT and the scratch
> descriptor array with early_memremap().
> 
> Move the call to the top of setup_arch(), which is how arm64 and x86
> already order it (early_fixmap_init()/early_ioremap_init() before
> setup_machine_fdt()/parse_setup_data()).  The BTMAP window is mapped
> into early_pg_dir by setup_vm(), and RISC-V neither calls
> early_ioremap_reset() nor defines __late_set_fixmap(), so the virtual
> addresses stay identical across the switch to the final page tables
> and nothing else in setup_arch() depends on the previous ordering.
> 
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103080926.2079-1-cp0613@linux.alibaba.com?part=2

Re: [PATCH v2 3/5] riscv: Add support for kexec handover (KHO)

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] riscv: kho: bootmem reservation fails when DRAM starts at or above 4 GiB
--

commit 25f3cc12aa8edcc1fbb1363f837f61e462a57ad6
Author: Chen Pei <cp0613@linux.alibaba.com>

riscv: Add support for kexec handover (KHO)

This commit enables kexec handover (KHO) support on 64-bit RISC-V systems with
MMU enabled by defining ARCH_SUPPORTS_KEXEC_HANDOVER in arch/riscv/Kconfig.

> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 435da07132437..e11463a923a32 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -1125,6 +1125,9 @@ config ARCH_SELECTS_KEXEC_FILE
>  config ARCH_SUPPORTS_KEXEC_PURGATORY
>  	def_bool ARCH_SUPPORTS_KEXEC_FILE
>  
> +config ARCH_SUPPORTS_KEXEC_HANDOVER
> +	def_bool 64BIT && MMU

[Severity: Medium]
As reported by Sashiko on v1 [1], will kho_reserve_bootmem() fail on 64-bit
RISC-V platforms where DRAM starts at or above 4 GiB, or record a 0-byte
region when all DRAM lies below 4 GiB?

Unlike arm64 (which defines ARCH_LOW_ADDRESS_LIMIT as arm64_dma_phys_limit - 1
and clamps it to memblock_end_of_DRAM() when DRAM starts above 4 GiB), RISC-V
falls back to the default in include/linux/memblock.h:

#ifndef ARCH_LOW_ADDRESS_LIMIT
#define ARCH_LOW_ADDRESS_LIMIT  0xffffffffUL
#endif

However, 64-bit RISC-V supports platforms where all DRAM starts at or above
4 GiB, as seen in arch/riscv/mm/init.c:arch_mm_preinit():

	bool swiotlb = max_pfn > PFN_DOWN(dma32_phys_limit) &&
		       memblock_start_of_DRAM() < dma32_phys_limit;

When KHO is enabled at boot, mm_core_init() -> kho_memory_init() ->
kho_reserve_bootmem() unconditionally allocates both lowmem and global bootmem
without checking whether their computed sizes in bootmem_size_update() are 0:

kernel/liveupdate/kexec_handover.c:kho_reserve_bootmem() {
	...
	size = bootmem_size_lowmem;
	addr = memblock_phys_alloc_range(size, BOOTMEM_ALIGNMENT_BYTES, 0,
					 ARCH_LOW_ADDRESS_LIMIT);
	if (!addr) {
		pr_err("Failed to reserve lowmem bootmem\n");
		goto err_free_bootmem_desc;
	}

	kho_bootmem[i].addr = addr;
	kho_bootmem[i].size = size;
	i++;

	/* reserve large contiguous area for allocations without nid */
	size = bootmem_size_global;
	addr = memblock_phys_alloc(size, BOOTMEM_ALIGNMENT_BYTES);
	if (!addr) {
		pr_err("Failed to reserve global bootmem\n");
		goto err_free_bootmem_areas;
	}
	...
}

On 64-bit RISC-V systems where DRAM starts at or above 4 GiB,
bootmem_size_lowmem is 0 and memblock_phys_alloc_range(0, ..., 0,
ARCH_LOW_ADDRESS_LIMIT) finds no memory below 0xffffffffUL, returning 0 and
disabling KHO. Conversely, when all DRAM lies below 4 GiB, bootmem_size_global
is 0 and kho_reserve_bootmem() records a 0-byte entry in kho_bootmem[], which
later causes kho_locate_mem_hole() to construct an inverted struct resource
with end = start - 1.

[1] https://lore.kernel.org/r/sashiko-outbox-183678@kernel.org

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103080926.2079-1-cp0613@linux.alibaba.com?part=3

Re: [PATCH v2 4/5] selftests: kho: Add riscv support

[sashiko-bot]

> Teach the KHO vmtest runner about riscv64: map the target to ARCH
> riscv and describe the QEMU virt machine, the kernel image and its
> console -- a 16550A port probed from the device tree on virt, hence
> the SERIAL_8250{,_CONSOLE} and SERIAL_OF_PLATFORM symbols.  Also
> select CONFIG_SPARSEMEM_MANUAL: the runner requires
> CONFIG_DEFERRED_STRUCT_PAGE_INIT, which depends on SPARSEMEM, while
> riscv falls back to FLATMEM (no ARCH_SPARSEMEM_DEFAULT), so without
> it the test would just be skipped.
> 
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103080926.2079-1-cp0613@linux.alibaba.com?part=4

Re: [PATCH v2 5/5] selftests: liveupdate: Add riscv support

[sashiko-bot]

> Teach the live update vmtest runner about riscv64: map the target to ARCH
> riscv, describe the QEMU virt machine, the kernel image and its console,
> and add the arch config fragment holding the three symbols needed to get
> a console on the virt machine's 16550A port.
> 
> KHO is the only dependency of LIVEUPDATE (kernel/liveupdate/Kconfig), so
> now that riscv has KHO the LUO tests only need the runner to stop
> rejecting the architecture.
> 
> Add riscv64 to the CROSS_COMPILE auto-detection list and to the target
> list of the batch runner as well, matching the existing aarch64/x86_64
> entries.
> 
> Signed-off-by: Chen Pei <cp0613@linux.alibaba.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103080926.2079-1-cp0613@linux.alibaba.com?part=5

Re: [PATCH v2 3/5] riscv: Add support for kexec handover (KHO)

[Chen Pei]

> As reported by Sashiko on v1 [1], will kho_reserve_bootmem() fail on 64-bit
> RISC-V platforms where DRAM starts at or above 4 GiB, or record a 0-byte
> region when all DRAM lies below 4 GiB?

Both, confirmed by measurement, and neither is riscv code. Mike Rapoport
has a patch that resolves it, so this series carries nothing for it:

https://lore.kernel.org/kexec/20261103-kho-bootmem-sizing-v1-1-45aa74098f34@kernel.org/

Best regards,
Chen