Hi, Pratyush, On Mon, Jul 13, 2026 at 9:53 PM Pratyush Yadav <[email protected]> wrote: > > On Mon, Jun 01 2026, George Guo wrote: > > > From: George Guo <[email protected]> > > > > Enable Kexec Handover (KHO) on LoongArch64 for FDT-based systems. > > > > - Kconfig: select ARCH_SUPPORTS_KEXEC_HANDOVER for CONFIG_64BIT > > - kexec.h: add fdt/fdt_mem fields to kimage_arch to hold the KHO FDT > > kexec segment virtual and physical addresses > > - machine_kexec_file.c: add kho_load_fdt() which copies the running > > kernel's FDT (initial_boot_params), appends linux,kho-fdt and > > linux,kho-scratch properties to /chosen, and loads the result as a > > kexec segment; called from load_other_segments(). Returns -EINVAL > > when initial_boot_params is NULL (ACPI-only boot) since that path > > requires separate handling. > > - machine_kexec.c: before jumping to the new kernel, update the > > DEVICE_TREE_GUID entry in the EFI config table to point to the KHO > > FDT segment so the second kernel finds it via efi_fdt_pointer() and > > early_init_dt_check_kho() calls kho_populate() > > > > Co-developed-by: Kexin Liu <[email protected]> > > Signed-off-by: Kexin Liu <[email protected]> > > Signed-off-by: George Guo <[email protected]> > > --- > > arch/loongarch/Kconfig | 3 + > > arch/loongarch/include/asm/kexec.h | 4 + > > arch/loongarch/kernel/machine_kexec.c | 27 +++++ > > arch/loongarch/kernel/machine_kexec_file.c | 118 +++++++++++++++++++++ > > 4 files changed, 152 insertions(+) > > > > diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig > > index 606597da46b8..d494418545f5 100644 > > --- a/arch/loongarch/Kconfig > > +++ b/arch/loongarch/Kconfig > > @@ -684,6 +684,9 @@ config ARCH_SUPPORTS_KEXEC > > config ARCH_SUPPORTS_KEXEC_FILE > > def_bool 64BIT > > > > +config ARCH_SUPPORTS_KEXEC_HANDOVER > > + def_bool 64BIT > > + > > config ARCH_SELECTS_KEXEC_FILE > > def_bool 64BIT > > depends on KEXEC_FILE > > diff --git a/arch/loongarch/include/asm/kexec.h > > b/arch/loongarch/include/asm/kexec.h > > index 209fa43222e1..adf54bfcdd49 100644 > > --- a/arch/loongarch/include/asm/kexec.h > > +++ b/arch/loongarch/include/asm/kexec.h > > @@ -39,6 +39,10 @@ struct kimage_arch { > > unsigned long efi_boot; > > unsigned long cmdline_ptr; > > unsigned long systable_ptr; > > +#ifdef CONFIG_KEXEC_HANDOVER > > + void *fdt; /* virtual address of KHO FDT segment buffer > > */ > > + unsigned long fdt_mem; /* physical address of KHO FDT segment */ > > +#endif > > }; > > > > #ifdef CONFIG_KEXEC_FILE > > diff --git a/arch/loongarch/kernel/machine_kexec.c > > b/arch/loongarch/kernel/machine_kexec.c > > index ad27fef098f1..98529c71d001 100644 > > --- a/arch/loongarch/kernel/machine_kexec.c > > +++ b/arch/loongarch/kernel/machine_kexec.c > > @@ -6,6 +6,7 @@ > > */ > > #include <linux/compiler.h> > > #include <linux/cpu.h> > > +#include <linux/efi.h> > > #include <linux/kexec.h> > > #include <linux/crash_dump.h> > > #include <linux/delay.h> > > @@ -289,6 +290,32 @@ void machine_kexec(struct kimage *image) > > pr_notice("We will call new kernel at 0x%lx\n", start_addr); > > pr_notice("Bye ...\n"); > > > > +#ifdef CONFIG_KEXEC_HANDOVER > > + /* > > + * Point the EFI FDTPTR config table entry at the modified FDT so the > > + * second kernel picks up the linux,kho-fdt and linux,kho-scratch > > + * properties via early_init_dt_check_kho(). > > + */ > > + if (internal->fdt_mem) { > > + /* > > + * FDT-based system: DEVICE_TREE_GUID already exists in the > > EFI > > + * config table; just update its pointer to our KHO FDT. > > + */ > > + efi_system_table_t *st = > > + (efi_system_table_t *)TO_CACHE(systable_ptr); > > + efi_config_table_t *ct = > > + (efi_config_table_t *)TO_CACHE((unsigned > > long)st->tables); > > + unsigned long i; > > + > > + for (i = 0; i < st->nr_tables; i++) { > > + if (!efi_guidcmp(ct[i].guid, DEVICE_TREE_GUID)) { > > + ct[i].table = (void *)internal->fdt_mem; > > + break; > > + } > > + } > > + } > > +#endif > > Honestly this and the ACPI stuff looks worse to me than what your > previous version did. Now I am not an expert on EFI and architecture > stuff, and know nothing about Loongarch, but to me this looks hacky and > I am not sure if it is doing the right thing. > > I think you should get some alignment with Loongarch maintainers on what > the kexec boot protocol looks like. It looked odd to me, but if the > Loongarch maintainers are fine with using the kernel cmdline for > bootloader to pass data to the kernel, then I think we should go back to > that. > > Huacai, do you have any thoughts? For KHO we essentially need a way for > the pre-kexec kernel to tell the post-kexec kernel about a blob of > memory that has some information it can use. For x86, we do that via > setup data. See arch/x86/include/uapi/asm/setup_data.h and struct > kho_data for example. On arm64, we use the boot FDT's /chosen node. See > kho_add_chosen() in drivers/of/kexec.c. > > Ideally, all device tree platforms should use the FDT path. But > Loongarch also has ACPI only and I don't know what a good idea for that > is. > > So, do you have any suggestions on where to best place a pointer to this > blob of data on Loongarch? v1 of this series put it in the kernel > commandline, but I found that odd and asked if it can be done via DT > instead. But to me, this code looks even more hacky. I don't know which is the best way, but I can give some information.
ARM64 and RISC-V create a FDT to contain all needed boot information (EFI system table, command line, etc.) in efistub. In other words, both ACPI booting and FDT booting have an existing FDT to pass the blob. But LoongArch is different, the efistub doesn't create a FDT, instead it passes the EFI system table and command line to the core kernel directly. Huacai > > > + > > /* Make reboot code buffer available to the boot CPU. */ > > flush_cache_all(); > > > [...] > > -- > Regards, > Pratyush Yadav
