* [PATCH 1/4] riscv: Call early_ioremap_setup() before parsing the DTB
2026-10-23 11:16 [PATCH 0/4] riscv: Enable kexec handover and live update Chen Pei
@ 2026-10-23 11:16 ` Chen Pei
2026-10-24 11:16 ` sashiko-bot
2026-10-23 11:16 ` [PATCH 2/4] riscv: Add support for kexec handover (KHO) Chen Pei
` (2 subsequent siblings)
3 siblings, 1 reply; 9+ messages in thread
From: Chen Pei @ 2026-10-23 11:16 UTC (permalink / raw)
To: pjw, palmer, alex, rppt, pasha.tatashin, pratyush, graf, shuah
Cc: guoren, linux-riscv, linux-kernel, linux-mm, linux-kselftest,
kexec
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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH 1/4] riscv: Call early_ioremap_setup() before parsing the DTB
2026-10-23 11:16 ` [PATCH 1/4] riscv: Call early_ioremap_setup() before parsing the DTB Chen Pei
@ 2026-10-24 11:16 ` sashiko-bot
0 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-10-24 11:16 UTC (permalink / raw)
To: Chen Pei, pjw, palmer, alex, rppt, pasha.tatashin, pratyush, graf,
shuah
Cc: guoren, kexec
> 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/20261023111612.2134-1-cp0613@linux.alibaba.com?part=1
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 2/4] riscv: Add support for kexec handover (KHO)
2026-10-23 11:16 [PATCH 0/4] riscv: Enable kexec handover and live update Chen Pei
2026-10-23 11:16 ` [PATCH 1/4] riscv: Call early_ioremap_setup() before parsing the DTB Chen Pei
@ 2026-10-23 11:16 ` Chen Pei
2026-10-24 11:16 ` sashiko-bot
2026-10-23 11:16 ` [PATCH 3/4] selftests: kho: Add riscv support Chen Pei
2026-10-23 11:16 ` [PATCH 4/4] selftests: liveupdate: " Chen Pei
3 siblings, 1 reply; 9+ messages in thread
From: Chen Pei @ 2026-10-23 11:16 UTC (permalink / raw)
To: pjw, palmer, alex, rppt, pasha.tatashin, pratyush, graf, shuah
Cc: guoren, linux-riscv, linux-kernel, linux-mm, linux-kselftest,
kexec
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 5874ca30f4f6..4f7d2f3f80b1 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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 2/4] riscv: Add support for kexec handover (KHO)
2026-10-23 11:16 ` [PATCH 2/4] riscv: Add support for kexec handover (KHO) Chen Pei
@ 2026-10-24 11:16 ` sashiko-bot
0 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-10-24 11:16 UTC (permalink / raw)
To: Chen Pei, pjw, palmer, alex, rppt, pasha.tatashin, pratyush, graf,
shuah
Cc: guoren, linux-mm, kexec
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] riscv: kho: BUG_ON() in linear_mapping_pa_to_va() during efi_init()
- [Medium] riscv: kho: bootmem reservation fails when DRAM starts at or above 4 GiB
--
commit 82f9788fea5dca057c5c8476c422bb40724521df
Author: Chen Pei <cp0613@linux.alibaba.com>
riscv: Add support for kexec handover (KHO)
This commit enables ARCH_SUPPORTS_KEXEC_HANDOVER on 64-bit RISC-V systems
with MMU support so that kexec handover (KHO) can be used on RISC-V.
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index e7891a2a89da6..a5c56252ff44a 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: High]
Can enabling ARCH_SUPPORTS_KEXEC_HANDOVER trigger a BUG_ON() in
linear_mapping_pa_to_va() during efi_init() when booting a KHO kexec kernel
on a 64-bit RISC-V UEFI system?
In arch/riscv/kernel/setup.c:setup_arch(), parse_dtb() runs before
efi_init(), and efi_init() runs before paging_init():
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();
efi_init();
paging_init();
During parse_dtb(), early_init_dt_scan() -> early_init_dt_check_kho() ->
kho_populate() sets kho_in.fdt_phys to the physical address of the handover
FDT.
Next, efi_init() -> reserve_regions() in drivers/firmware/efi/efi-init.c
checks is_kho_boot(), which calls kho_get_fdt() in
kernel/liveupdate/kexec_handover.c:
static const void *kho_get_fdt(void)
{
return kho_in.fdt_phys ? phys_to_virt(kho_in.fdt_phys) : NULL;
}
However, on 64-bit RISC-V, kernel_map.va_pa_offset is initialized to 0UL in
setup_vm() and is not populated until paging_init() -> setup_bootmem() in
arch/riscv/mm/init.c:
/*
* In 64-bit, any use of __va/__pa before this point is wrong as we
* did not know the start of DRAM before.
*/
if (IS_ENABLED(CONFIG_64BIT) && IS_ENABLED(CONFIG_MMU))
kernel_map.va_pa_offset = PAGE_OFFSET - phys_ram_base;
When CONFIG_DEBUG_VIRTUAL=y is enabled, calling phys_to_virt(kho_in.fdt_phys)
before setup_bootmem() reaches linear_mapping_pa_to_va() in
arch/riscv/mm/physaddr.c:
void *linear_mapping_pa_to_va(unsigned long x)
{
BUG_ON(!kernel_map.va_pa_offset);
return ((void *)((unsigned long)(x) + kernel_map.va_pa_offset));
}
Would this panic the incoming kernel during efi_init() (or compute an
untranslated address in kho_get_fdt() when CONFIG_DEBUG_VIRTUAL=n)?
[Severity: Medium]
Also, 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 via arm64_dma_phys_limit),
RISC-V uses the default ARCH_LOW_ADDRESS_LIMIT of 0xffffffffUL from
include/linux/memblock.h, while arch_mm_preinit() in arch/riscv/mm/init.c
supports systems where memblock_start_of_DRAM() >= dma32_phys_limit (4 GiB)
or max_pfn <= PFN_DOWN(dma32_phys_limit).
In kernel/liveupdate/kexec_handover.c:kho_reserve_bootmem(), both the lowmem
and global allocations are performed unconditionally without checking whether
bootmem_size_lowmem or bootmem_size_global is 0:
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 systems where all DRAM starts at or above 4 GiB, bootmem_size_lowmem is 0
and memblock_phys_alloc_range(0, BOOTMEM_ALIGNMENT_BYTES, 0,
ARCH_LOW_ADDRESS_LIMIT) finds no memory below 0xffffffffUL, returning 0 and
disabling KHO. Conversely, on systems where all DRAM is below 4 GiB,
bootmem_size_global is 0 and memblock_phys_alloc(0, BOOTMEM_ALIGNMENT_BYTES)
records a 0-byte entry in kho_bootmem[].
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261023111612.2134-1-cp0613@linux.alibaba.com?part=2
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 3/4] selftests: kho: Add riscv support
2026-10-23 11:16 [PATCH 0/4] riscv: Enable kexec handover and live update Chen Pei
2026-10-23 11:16 ` [PATCH 1/4] riscv: Call early_ioremap_setup() before parsing the DTB Chen Pei
2026-10-23 11:16 ` [PATCH 2/4] riscv: Add support for kexec handover (KHO) Chen Pei
@ 2026-10-23 11:16 ` Chen Pei
2026-10-24 11:16 ` sashiko-bot
2026-10-23 11:16 ` [PATCH 4/4] selftests: liveupdate: " Chen Pei
3 siblings, 1 reply; 9+ messages in thread
From: Chen Pei @ 2026-10-23 11:16 UTC (permalink / raw)
To: pjw, palmer, alex, rppt, pasha.tatashin, pratyush, graf, shuah
Cc: guoren, linux-riscv, linux-kernel, linux-mm, linux-kselftest,
kexec
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.3.0-rc7-00108-gc6e90ee4ccbb (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 0014bd76e88d..325af59f653a 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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH 3/4] selftests: kho: Add riscv support
2026-10-23 11:16 ` [PATCH 3/4] selftests: kho: Add riscv support Chen Pei
@ 2026-10-24 11:16 ` sashiko-bot
0 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-10-24 11:16 UTC (permalink / raw)
To: Chen Pei, pjw, palmer, alex, rppt, pasha.tatashin, pratyush, graf,
shuah
Cc: guoren, kexec
> 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/20261023111612.2134-1-cp0613@linux.alibaba.com?part=3
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 4/4] selftests: liveupdate: Add riscv support
2026-10-23 11:16 [PATCH 0/4] riscv: Enable kexec handover and live update Chen Pei
` (2 preceding siblings ...)
2026-10-23 11:16 ` [PATCH 3/4] selftests: kho: Add riscv support Chen Pei
@ 2026-10-23 11:16 ` Chen Pei
2026-10-24 11:16 ` sashiko-bot
3 siblings, 1 reply; 9+ messages in thread
From: Chen Pei @ 2026-10-23 11:16 UTC (permalink / raw)
To: pjw, palmer, alex, rppt, pasha.tatashin, pratyush, graf, shuah
Cc: guoren, linux-riscv, linux-kernel, linux-mm, linux-kselftest,
kexec
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
# [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 64fd2ab55b76..ee554d889e1b 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
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH 4/4] selftests: liveupdate: Add riscv support
2026-10-23 11:16 ` [PATCH 4/4] selftests: liveupdate: " Chen Pei
@ 2026-10-24 11:16 ` sashiko-bot
0 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-10-24 11:16 UTC (permalink / raw)
To: Chen Pei, pjw, palmer, alex, rppt, pasha.tatashin, pratyush, graf,
shuah
Cc: guoren, kexec
> 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/20261023111612.2134-1-cp0613@linux.alibaba.com?part=4
^ permalink raw reply [flat|nested] 9+ messages in thread