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

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

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.