On Mon, Aug 10 2026, Huacai Chen wrote: > 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.
Agreed. Perhaps we can move x86 over to use this as well? If I understand correctly, pretty much all modern x86 systems have UEFI, so it would make sense for KHO to directly use the generic UEFI bits for x86 as well instead of having it via setup data. > > BTW, I think LINUX_EFI_KEXEC_HANDOVER_GUID may be a little better than > LINUX_EFI_KHO_TABLE_GUID. +1, that sounds better. -- Regards, Pratyush Yadav
