Re: [PATCH] efi/x86-stub: store acpi_rsdp_addr in bootparams

["Ard Biesheuvel" <ardb@kernel.org>]

On Thu, 19 Feb 2026, at 07:57, Dave Young wrote:
> Hi Ard,
>
>> Actually, looking at that code more closely, I kind of wonder why the kexec code tests for EFI_RUNTIME_SERVICES to begin with. Perhaps it might be sufficient to do this:
>>
>> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
>> index c3244ac680d1..bec91ee7e668 100644
>> --- a/arch/x86/kernel/kexec-bzimage64.c
>> +++ b/arch/x86/kernel/kexec-bzimage64.c
>> @@ -192,7 +192,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
>>         struct efi_info *current_ei = &boot_params.efi_info;
>>         struct efi_info *ei = &params->efi_info;
>>
>> -       if (!efi_enabled(EFI_RUNTIME_SERVICES))
>> +       if (!efi_enabled(EFI_MEMMAP))
>>                 return 0;
>>
>>         if (!current_ei->efi_memmap_size)
>>
>> That way, if the first kernel was booted via EFI but without runtime services enabled, the kexec'ed kernel will simply inherit the ACPI and EFI tables.
>
> Actually it does not work,  EFI_MEMMAP is unset in function
> efi_memmap_unmap() when runtime is disabled,  so nodifference for
> checking EFI_MEMMAP or EFI_RUNTIME_SERVICES bits.
>
> The x86 kexec efi code is simply written to assume EFI runtime is
> enabled as it copies the cooked runtime service mem ranges in memmap.
>  If we want to improve it I suspect the efi initialization code could
> need changes, and then even if first kernel disabled runtime, the
> kexec 2nd kernel still have chance to enter virtual mode to enable
> runtime.    But this does requires more work to be done.
>

Yeah, fixing that seems a bit risky, and not really worth the reward.