Re: [PATCH v6 1/8] efi: Pass KHO state to the next kernel in a configuration table

[Pratyush Yadav <pratyush@kernel.org>]

Hi Ard,

On Thu, Oct 29 2026, Ard Biesheuvel wrote:

> On Thu, 29 Oct 2026, at 18:29, George Guo wrote:
>> From: George Guo <guodongtai@kylinos.cn>
>>
>> KHO has to give the next kernel two addresses: the KHO FDT and the
>> bootmem area list. arm64 and riscv put them under /chosen in the boot
>> FDT. LoongArch systems booting with EFI and ACPI do not require a boot
>> FDT, so KHO needs another way to pass this information.
>>
>> Add a Linux EFI configuration table for them, under
>> LINUX_EFI_KEXEC_HANDOVER_GUID. It points to a struct linux_efi_kho_data.
>>
>>   - On a cold boot, the LoongArch EFI stub installs the table, zeroed.
>>     Each kexec'd kernel is given the same EFI system table, so it finds
>>     the same table.
>>
>>   - In early boot, efi_config_parse_tables() reserves the table so
>>     neither the page allocator nor kexec segments use it, and calls
>>     kho_populate() if the table holds KHO state.
>>
>>   - Provide efi_kho_update() to update the table before kexec. Map the
>>     table during boot so updates do not require allocation or mapping
>>     at panic time.
>>
>>   - efi_kho_table_found() tells architecture code whether the table was
>>     found at boot, so it can turn KHO off when the table is missing.
>>
>> Only the LoongArch stub installs the table, and only with
>> CONFIG_KEXEC_HANDOVER. Elsewhere there is no table and this code does
>> nothing.
>>
>
> Can we handle this as an arch table then, and handle everything in
> the LoongArch arch code?

I think this is useful for all architectures that use EFI, not only
Loongarch. Today Loongarch is the only user, but this can very easily be
used by other architectures.

For example, I have been considering moving x86 over to this too. Today
we use setup_data. Once we get EFI support, I would like to get rid of
that and unify everything under EFI. It is much simpler to have a
universal way to pass KHO payload over.

-- 
Regards,
Pratyush Yadav