linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yao Zi <ziyao@disroot.org>
To: Youling Tang <youling.tang@linux.dev>,
	Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>, Baoquan He <bhe@redhat.com>,
	kexec@lists.infradead.org, loongarch@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	Youling Tang <tangyouling@kylinos.cn>
Subject: Re: [PATCH 2/6] LoongArch: Add kexec_file support
Date: Tue, 12 Aug 2025 09:43:13 +0000	[thread overview]
Message-ID: <aJsGg8__ppyBrkfL@pie> (raw)
In-Reply-To: <af866071-81c1-44d5-ae02-273d6e9c04d4@linux.dev>

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@kylinos.cn>
> > > > 
> > > > 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@kylinos.cn>
> > > > ---
> > > >   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?

> 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.

> 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

  reply	other threads:[~2025-08-12  9:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-11  9:26 [PATCH 0/6] Add kexec_file support for LoongArch Youling Tang
2025-08-11  9:26 ` [PATCH 1/6] LoongArch: Add struct loongarch_image_header for kernel image Youling Tang
2025-08-11  9:26 ` [PATCH 2/6] LoongArch: Add kexec_file support Youling Tang
2025-08-11 14:07   ` Huacai Chen
2025-08-12  1:21     ` Youling Tang
2025-08-12  1:53       ` Yanteng Si
2025-08-12  9:32         ` Youling Tang
2025-08-13  1:15           ` Yanteng Si
2025-08-12  2:53       ` Huacai Chen
2025-08-11 17:06   ` Yao Zi
2025-08-12  2:39     ` Huacai Chen
2025-08-12  7:56       ` Yao Zi
2025-08-12  6:15     ` Youling Tang
2025-08-12  7:06       ` Youling Tang
2025-08-12  9:43         ` Yao Zi [this message]
2025-08-13  2:18           ` Youling Tang
2025-08-13  3:24             ` Yao Zi
2025-08-16  5:37   ` kernel test robot
2025-08-11  9:26 ` [PATCH 3/6] LoongArch/kexec_file: Add initrd loading Youling Tang
2025-08-11 14:12   ` Huacai Chen
2025-08-12  2:38     ` Youling Tang
2025-08-12  3:03       ` Huacai Chen
2025-08-11 17:58   ` Yao Zi
2025-08-12  4:05     ` Youling Tang
2025-08-12  6:25       ` Yao Zi
2025-08-11  9:26 ` [PATCH 4/6] LoongArch/kexec_file: Add crash dump support Youling Tang
2025-08-11  9:26 ` [PATCH 5/6] LoongArch/kexec_file: Add "mem" parameter to limit memory usage of kdump kernel Youling Tang
2025-08-11  9:26 ` [PATCH 6/6] LoongArch: Enable CONFIG_KEXEC_FILE Youling Tang
2025-08-11 16:20 ` [PATCH 0/6] Add kexec_file support for LoongArch Vincent Li
2025-08-12  6:21   ` Youling Tang

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=aJsGg8__ppyBrkfL@pie \
    --to=ziyao@disroot.org \
    --cc=bhe@redhat.com \
    --cc=chenhuacai@kernel.org \
    --cc=kernel@xen0n.name \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=tangyouling@kylinos.cn \
    --cc=youling.tang@linux.dev \
    /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;
as well as URLs for NNTP newsgroup(s).