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

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

[Dave Young]

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(+)

Index: linux-x86/drivers/firmware/efi/libstub/x86-stub.c
===================================================================
--- linux-x86.orig/drivers/firmware/efi/libstub/x86-stub.c
+++ linux-x86/drivers/firmware/efi/libstub/x86-stub.c
@@ -484,6 +484,22 @@ static void setup_quirks(struct boot_par
 	}
 }
 
+static void setup_acpi_rsdp(struct boot_params *boot_params)
+{
+	u64 rsdp_addr;
+
+	/*
+	 * Search EFI system tables for RSDP. Preferred is ACPI_20_TABLE_GUID to
+	 * ACPI_TABLE_GUID because it has more features.
+	 */
+	rsdp_addr = (u64)get_efi_config_table(ACPI_20_TABLE_GUID);
+	if (!rsdp_addr)
+		rsdp_addr = (u64)get_efi_config_table(ACPI_TABLE_GUID);
+
+	if (rsdp_addr)
+		boot_params->acpi_rsdp_addr = rsdp_addr;
+}
+
 static void setup_graphics(struct boot_params *boot_params)
 {
 	struct screen_info *si = memset(&boot_params->screen_info, 0, sizeof(*si));
@@ -1017,6 +1033,8 @@ void __noreturn efi_stub_entry(efi_handl
 
 	setup_graphics(boot_params);
 
+	setup_acpi_rsdp(boot_params);
+
 	setup_efi_pci(boot_params);
 
 	setup_quirks(boot_params);

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

[Ard Biesheuvel]

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?

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

[Dave Young]

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.  Otherwise it seems the early
acpi_rsdp_addr was introduced for other reason (KASLR) although I'm
not sure about the exact background:   (Before this the original kexec
fallback just depend on end user to put acpi_rsdp in kernel cmdline
explictily or in kexec-tools)
commit 3a63f70bf4c3a17f5d9c9bf3bc3288a23bdfefce
Author: Chao Fan <fanc.fnst@cn.fujitsu.com>
Date:   Wed Jan 23 19:08:48 2019 +0800

    x86/boot: Early parse RSDP and save it in boot_params

Another thing is I do not have much time to work on big changes in
recent years, so if you suggest to have a resturcture I have to give
up :)   But I'm happy to do some trival thing during this week as I'm
in a holiday break and I have some time to play with it.

Thanks
Dave

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

[Ard Biesheuvel]

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?

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 7508d0ccc740..24aec7c1153f 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -313,6 +313,12 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
 
        /* Always fill in RSDP: it is either 0 or a valid value */
        params->acpi_rsdp_addr = boot_params.acpi_rsdp_addr;
+       if (IS_ENABLED(CONFIG_EFI) && !params->acpi_rsdp_addr) {
+               if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
+                       params->acpi_rsdp_addr = efi.acpi20;
+               else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
+                       params->acpi_rsdp_addr = efi.acpi;
+       }
 
        /* Default APM info */
        memset(&params->apm_bios_info, 0, sizeof(params->apm_bios_info));

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

[Dave Young]

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.

>
> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> index 7508d0ccc740..24aec7c1153f 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -313,6 +313,12 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
>
>         /* Always fill in RSDP: it is either 0 or a valid value */
>         params->acpi_rsdp_addr = boot_params.acpi_rsdp_addr;
> +       if (IS_ENABLED(CONFIG_EFI) && !params->acpi_rsdp_addr) {
> +               if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> +                       params->acpi_rsdp_addr = efi.acpi20;
> +               else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> +                       params->acpi_rsdp_addr = efi.acpi;
> +       }
>
>         /* Default APM info */
>         memset(&params->apm_bios_info, 0, sizeof(params->apm_bios_info));
>

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

[Ard Biesheuvel]

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.

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

[Dave Young]

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!

Dave

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

[Ard Biesheuvel]

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.

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

[Dave Young]

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.

Thanks
Dave

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

[Ard Biesheuvel]

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.

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

[Dave Young]

> > > 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.

FYI, the changes work with the latest upstream kexec-tools,
In case someone is curious, it fixed the wrong "%lux" with ""0x%" PRIx64"

Thanks
Dave