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

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

On Tue, 17 Feb 2026, at 11:29, Dave Young wrote:
> On Tue, 17 Feb 2026 at 18:27, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>>
>>
>> On Tue, 17 Feb 2026, at 11:01, Dave Young wrote:
>> > On Tue, 17 Feb 2026 at 17:20, Ard Biesheuvel <ardb@kernel.org> wrote:
>> >>
>> >>
>> >> On Tue, 17 Feb 2026, at 09:19, Dave Young wrote:
>> >> > Hi Ard,
>> >> >
>> >> > On Tue, 17 Feb 2026 at 16:10, Ard Biesheuvel <ardb@kernel.org> wrote:
>> >> >>
>> >> >> Hi Dave,
>> >> >>
>> >> >> On Tue, 17 Feb 2026, at 09:04, Dave Young wrote:
>> >> >> > Kernel panic occurs during a kexec reboot when EFI runtime services
>> >> >> > are not enabled in the first kernel. The issue is that the second
>> >> >> > kernel cannot find the ACPI RSDP address during boot.
>> >> >> >
>> >> >> > In legacy boot, the acpi_rsdp_addr is set in early x86 boot code.
>> >> >> > However, kernel decompression has moved to the EFI stub for EFI boot.
>> >> >> > Therefore, the x86 EFI stub must also be updated to store the
>> >> >> > acpi_rsdp_addr in the boot parameters to ensure the kexec kernel
>> >> >> > can find it.
>> >> >> >
>> >> >> > (Note: If the pre-kexec kernel was itself a kexec boot, the later kexec
>> >> >> > reboot will still utilize the legacy decompressor path, so the original
>> >> >> > code remains functional though some cleanups can be done later.)
>> >> >> >
>> >> >> > Signed-off-by: Dave Young <dyoung@redhat.com>
>> >> >> > ---
>> >> >> >  drivers/firmware/efi/libstub/x86-stub.c |   18 ++++++++++++++++++
>> >> >> >  1 file changed, 18 insertions(+)
>> >> >> >
>> >> >>
>> >> >> If this issue is kexec-specific, can we move this to where the kexec code prepares the boot_params struct for the next kernel?
>> >> >>
>> >> >
>> >> > The kexec use case is it depends on the pre-kexec kernel saving it
>> >> > during boot for noefi case.  I do not have a better idea to do it in
>> >> > kexec code for the time being.
>> >>
>> >> How about something like this?
>> >
>> > Thanks!  It works for me, however the legacy kexec_load syscall still
>> > failed with a panic I did not dig into the root cause yet, I supposed
>> > it will find the rsdp from /sys/firmware/efi/systab file, maybe some
>> > userspace code bug.
>> >
>> > Anyway I'm fine with this fix,  would you like to send a formal patch
>> > since you proposed it?  Otherwise I will resend with the changes.
>> >
>>
>> Excellent. I'll queue it with a link to this thread.
>>
>
> Thanks a lot!
>

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.