Re: [PATCH 2/4] riscv: Add support for kexec handover (KHO)

[sashiko-bot@kernel.org]

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