Re: [PATCH 2/6] LoongArch: Add kexec_file support

[Youling Tang]

Hi, Yao
On 2025/8/12 17:43, Yao Zi wrote:
> On Tue, Aug 12, 2025 at 03:06:23PM +0800, Youling Tang wrote:
> > On 2025/8/12 14:15, Youling Tang wrote:
> > > Hi, Yao
> > > On 2025/8/12 01:06, Yao Zi wrote:
> > > > On Mon, Aug 11, 2025 at 05:26:55PM +0800, Youling Tang wrote:
> > > > > From: Youling Tang <tangyouling@xxxxxxxxxx>
> > > > >
> > > > > This patch adds support for kexec_file on LoongArch.
> > > > >
> > > > > The image_load() as two parts:
> > > > > - the first part loads the kernel image (vmlinuz.efi or vmlinux.efi)
> > > > > - the second part loads other segments (eg: initrd, cmdline)
> > > > >
> > > > > Currently, pez(vmlinuz.efi) and pei(vmlinux.efi) format images
> > > > > are supported,
> > > > > but ELF format is not supported.
> > > > >
> > > > > Signed-off-by: Youling Tang <tangyouling@xxxxxxxxxx>
> > > > > ---
> > > > >    arch/loongarch/Kconfig                     |   8 ++
> > > > >    arch/loongarch/include/asm/image.h         |  18 ++++
> > > > >    arch/loongarch/include/asm/kexec.h         |  12 +++
> > > > >    arch/loongarch/kernel/Makefile             |   1 +
> > > > >    arch/loongarch/kernel/kexec_image.c        | 112
> > > > > +++++++++++++++++++++
> > > > >    arch/loongarch/kernel/machine_kexec.c      |  33 ++++--
> > > > >    arch/loongarch/kernel/machine_kexec_file.c |  46 +++++++++
> > > > >    7 files changed, 219 insertions(+), 11 deletions(-)
> > > > >    create mode 100644 arch/loongarch/kernel/kexec_image.c
> > > > >    create mode 100644 arch/loongarch/kernel/machine_kexec_file.c
> ...
>
> > > > > diff --git a/arch/loongarch/kernel/kexec_image.c
> > > > > b/arch/loongarch/kernel/kexec_image.c
> > > > > new file mode 100644
> > > > > index 000000000000..fdd1845b4e2e
> > > > > --- /dev/null
> > > > > +++ b/arch/loongarch/kernel/kexec_image.c
> ...
>
> > > > > +    /*
> > > > > +     * The location of the kernel segment may make it
> > > > > impossible to satisfy
> > > > > +     * the other segment requirements, so we try repeatedly to find a
> > > > > +     * location that will work.
> > > > > +     */
> > > > > +    while ((ret = kexec_add_buffer(&kbuf)) == 0) {
> > > > > +        /* Try to load additional data */
> > > > > +        kernel_segment = &image->segment[kernel_segment_number];
> > > > > +        ret = load_other_segments(image, kernel_segment->mem,
> > > > > +                      kernel_segment->memsz, initrd,
> > > > > +                      initrd_len, cmdline, cmdline_len);
> > > > > +        if (!ret)
> > > > > +            break;
> > > > > +
> > > > > +        /*
> > > > > +         * We couldn't find space for the other segments; erase the
> > > > > +         * kernel segment and try the next available hole.
> > > > > +         */
> > > > > +        image->nr_segments -= 1;
> > > > > +        kbuf.buf_min = kernel_segment->mem + kernel_segment->memsz;
> > > > > +        kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> > > > > +    }
> > > > > +
> > > > > +    if (ret) {
> > > > > +        pr_err("Could not find any suitable kernel location!");
> > > > > +        return ERR_PTR(ret);
> > > > > +    }
> > > > > +
> > > > > +    kernel_segment = &image->segment[kernel_segment_number];
> > > > > +
> > > > > +    /* Make sure the second kernel jumps to the correct
> > > > > "kernel_entry". */
> > > > > +    image->start = kernel_segment->mem + h->kernel_entry -
> > > > > text_offset;
> > > > A non-relocatable loongarch kernel cannot be loaded to arbitrary
> > > > address. Thus this loading function seems to only work for relocatable
> > > > kernels, maybe it's better to leave a comment indicating the limitation.
> > > >
> > > > For now, we don't seem to have a way to find out whether the kernel is
> > > > relocatable (for example, a flag in kernel image header), so it's
> > > > impossible to point out whether the loaded kernel boots fine with
> > > > arbitrary loading address...
> > > LoongArch enables the relocation of the kernel when the kdump
> > > feature is enabled.
> > >
> > > config ARCH_SELECTS_CRASH_DUMP
> > >          def_bool y
> > >          depends on CRASH_DUMP
> > >          select RELOCATABLE
> This only means the currently-running kernel is relocatable, not the one
> being exec'ed, right?
No.
> > When enabling KEXEC_FILE, the RELOCATABLE configuration should
> > also be enabled. Both kexec and kdump require this.
> I'm not sure whether you're talking about the running kernel or the one
> that is going to be exec'ed. This method of kernel loading requires the
> exec'ed kernel being relocatable, not the currently running one.
>
> And I think it's totally reasonable to use KEXEC_FILE for non-crash-dump
> purpose, for example, linuxboot. It'll be confusing to the user if the
> system just hangs after booting a non-relocatable kernel, which is hard
> to debug.
>
> Thus IMHO we should ideally refuse to load non-relocatable kernels, or
> add a FIXME comment to indicate the situation that it's impossible to
> determine whether the exec'ed image is relocatable.
The first kernel and the second kernel are generally the same kernel
(the same image). When KEXEC_FILE is enabled and RELOCATEABLE
is enabled by default, it has been forcibly guaranteed that both the
first kernel and the second kernel are relocatable kernels regardless
of kexec/kdump operations.

Unless the second kernel it loads is an older version of the kernel (the
older version of the kernel does not use the default configuration, with
CONFIG_KEXEC enabled but CONFIG_CRASH_DUMP disabled, this is not acorrect
usage).

Thanks,
Youling.
> > Youling.
> > > After enabling the relocation, LoongArch is the PIE kernel. For
> > > more details, please refer to commit d8da19fbdedd ("LoongArch:
> > > Add support for kernel relocation")
> Best regards.
> Yao Zi