From: sashiko-bot@kernel.org
To: "Chen Pei" <cp0613@linux.alibaba.com>,
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-mm@kvack.org, kexec@lists.infradead.org
Subject: Re: [PATCH v2 3/5] riscv: Add support for kexec handover (KHO)
Date: Wed, 04 Nov 2026 08:10:23 +0000 [thread overview]
Message-ID: <sashiko-outbox-196857@kernel.org> (raw)
In-Reply-To: <20261103080926.2079-4-cp0613@linux.alibaba.com>
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
next prev parent reply other threads:[~2026-11-04 8:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 8:09 [PATCH v2 0/5] riscv: Enable kexec handover and live update Chen Pei
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-04 8:10 ` sashiko-bot
2026-11-03 8:09 ` [PATCH v2 2/5] riscv: Call early_ioremap_setup() before parsing the DTB Chen Pei
2026-11-04 8:10 ` sashiko-bot
2026-11-03 8:09 ` [PATCH v2 3/5] riscv: Add support for kexec handover (KHO) Chen Pei
2026-11-04 8:10 ` sashiko-bot [this message]
2026-11-04 13:45 ` Chen Pei
2026-11-03 8:09 ` [PATCH v2 4/5] selftests: kho: Add riscv support Chen Pei
2026-11-04 8:10 ` sashiko-bot
2026-11-03 8:09 ` [PATCH v2 5/5] selftests: liveupdate: " Chen Pei
2026-11-04 8:10 ` sashiko-bot
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=sashiko-outbox-196857@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alex@ghiti.fr \
--cc=cp0613@linux.alibaba.com \
--cc=graf@amazon.com \
--cc=guoren@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=palmer@dabbelt.com \
--cc=pasha.tatashin@soleen.com \
--cc=pjw@kernel.org \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--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