Re: [PATCH v4 1/4] efi: add a KHO configuration table GUID
Huacai Chen <[email protected]>
| Newsgroups | org.kernel.vger.linux-efi,dev.linux.lists.loongarch,org.infradead.lists.kexec,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kvack.linux-mm |
|---|---|
| Message-ID | <CAAhV-H4xxPXVRNXP42CBtMdVXbBZ4E6A997jZmw7HpEUSFAj9g@mail.gmail.com> |
Hi, George, On Fri, Aug 7, 2026 at 6:38 PM George Guo <[email protected]> wrote: > > From: George Guo <[email protected]> > > Kexec Handover (KHO) passes the address of its state FDT and of its > scratch area from the current kernel to the next one. On architectures > that boot with a device tree, the current kernel writes the > linux,kho-fdt and linux,kho-scratch properties into /chosen, and the next > kernel reads them back in early_init_dt_check_kho(). > > Architectures that boot through EFI without a device tree have no such > channel. LoongArch is one of them: its efistub passes the EFI system > table and the command line to the core kernel directly and never creates > an FDT. x86 has the same problem and carries the state out of band > instead, in a struct kho_data in the setup_data chain of its boot > protocol. > > Add an out-of-band channel for EFI: a LINUX_EFI_KHO_TABLE_GUID > configuration table entry, under a randomly generated GUID, pointing at a > struct linux_efi_kho_data. The > current kernel loads the structure and an extended configuration table as > kexec segments, then switches the EFI system table to the new table > before jumping. The next kernel finds the entry by GUID and calls > kho_populate(). > > The structure carries no version field. An incompatible change to the > layout must use a new GUID, which is the usual rule for EFI configuration > tables. The handover payload itself is versioned separately, by the > compatible string of the KHO state FDT that kho_populate() checks. > > This patch adds the definitions only. LoongArch is the first user; any > other EFI architecture without a boot FDT can use the same channel. > > Signed-off-by: George Guo <[email protected]> > --- > include/linux/efi.h | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/include/linux/efi.h b/include/linux/efi.h > index ccbc35479684..789ab9e4312a 100644 > --- a/include/linux/efi.h > +++ b/include/linux/efi.h > @@ -422,6 +422,7 @@ void efi_native_runtime_setup(void); > #define LINUX_EFI_COCO_SECRET_AREA_GUID EFI_GUID(0xadf956ad, 0xe98c, 0x484c, 0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47) > #define LINUX_EFI_BOOT_MEMMAP_GUID EFI_GUID(0x800f683f, 0xd08b, 0x423a, 0xa2, 0x93, 0x96, 0x5c, 0x3c, 0x6f, 0xe2, 0xb4) > #define LINUX_EFI_UNACCEPTED_MEM_TABLE_GUID EFI_GUID(0xd5d1de3c, 0x105c, 0x44f9, 0x9e, 0xa9, 0xbc, 0xef, 0x98, 0x12, 0x00, 0x31) > +#define LINUX_EFI_KHO_TABLE_GUID EFI_GUID(0xc941b6c7, 0x7b3f, 0x4af6, 0x9e, 0x50, 0xfc, 0xb3, 0xa8, 0x86, 0x8a, 0x17) I don't know whether it is allowed to define a new TABLE ID while doesn't touch the UEFI SPEC. Huacai > > #define RISCV_EFI_BOOT_PROTOCOL_GUID EFI_GUID(0xccd15fec, 0x6f73, 0x4eec, 0x83, 0x95, 0x3e, 0x69, 0xe4, 0xb9, 0x40, 0xbf) > > @@ -1271,6 +1272,29 @@ struct linux_efi_memreserve { > > void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size); > > +/* > + * The LINUX_EFI_KHO_TABLE_GUID config table points to this structure. It > + * carries the kexec handover (KHO) state from the current kernel to the next > + * one: the addresses of the KHO state FDT and of the scratch area. > + * > + * This is the handover channel for architectures that boot through EFI without > + * a device tree, where the /chosen linux,kho-fdt and linux,kho-scratch > + * properties read by early_init_dt_check_kho() are not available. The current > + * kernel loads the structure and an extended configuration table as kexec > + * segments; the next kernel finds it by GUID and calls kho_populate(). > + * > + * The layout is an ABI between the two kernels and is fixed. It carries no > + * version field: an incompatible change must use a new GUID, and the handover > + * payload itself is versioned separately by the compatible string of the KHO > + * state FDT, which kho_populate() checks. > + */ > +struct linux_efi_kho_data { > + u64 fdt_addr; > + u64 fdt_size; > + u64 scratch_addr; > + u64 scratch_size; > +} __packed; > + > /* > * The LINUX_EFI_MOK_VARIABLE_TABLE_GUID config table can be provided > * to the kernel by an EFI boot loader. The table contains a packed > -- > 2.53.0 >