On Mon, Aug 10, 2026 at 9:14 PM Ard Biesheuvel <[email protected]> wrote: > > > > On Sun, 9 Aug 2026, at 06:18, Huacai Chen wrote: > > 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. > > > > That is fine in principle: the whole reason for using GUIDs as identifiers > in UEFI is that everyone can invent their own, and the risk of conflicts is > negligible. > > All LINUX_EFI_* GUIDs are Linux inventions, and are not mentioned in the > UEFI spec at all. OK, then I think the direction of this series is correct now, and I hope there will be more archs share this GUID.
BTW, I think LINUX_EFI_KEXEC_HANDOVER_GUID may be a little better than LINUX_EFI_KHO_TABLE_GUID. Huacai >
