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 <tangyoul...@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 <tangyoul...@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?
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
