On Tue, 17 Feb 2026, at 11:29, Dave Young wrote:
> On Tue, 17 Feb 2026 at 18:27, Ard Biesheuvel <[email protected]> wrote:
>>
>>
>>
>> On Tue, 17 Feb 2026, at 11:01, Dave Young wrote:
>> > On Tue, 17 Feb 2026 at 17:20, Ard Biesheuvel <[email protected]> wrote:
>> >>
>> >>
>> >> On Tue, 17 Feb 2026, at 09:19, Dave Young wrote:
>> >> > Hi Ard,
>> >> >
>> >> > On Tue, 17 Feb 2026 at 16:10, Ard Biesheuvel <[email protected]> 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 <[email protected]>
>> >> >> > ---
>> >> >> > 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 = ¶ms->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.
