Re: [PATCH v4 1/4] efi: add a KHO configuration table GUID

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.