Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map

From: Rafael J. Wysocki
Date: Wed Jan 16 2019 - 17:24:20 EST

On 1/16/2019 7:51 AM, Dave Young wrote:
On 01/16/19 at 01:09pm, Kairui Song wrote:
On Wed, Jan 16, 2019 at 11:32 AM Dave Young <dyoung@xxxxxxxxxx> wrote:
On 01/16/19 at 12:10am, Borislav Petkov wrote:
On Tue, Jan 15, 2019 at 05:58:34PM +0800, Kairui Song wrote:
When efi=noruntime or efi=oldmap is used, EFI services won't be available
in the second kernel, therefore the second kernel will not be able to get
the ACPI RSDP address from firmware by calling EFI services and won't
boot. Previously we are expecting the user to set the acpi_rsdp=<addr>
on kernel command line for second kernel as there was no way to pass RSDP
address to second kernel.

After commit e6e094e053af ('x86/acpi, x86/boot: Take RSDP address from
boot params if available'), now it's possible to set an acpi_rsdp_addr
parameter in the boot_params passed to second kernel, this commit make
use of it, detect and set the RSDP address when it's required for second
kernel to boot.

Tested with an EFI enabled KVM VM with efi=noruntime.

Suggested-by: Dave Young <dyoung@xxxxxxxxxx>
Signed-off-by: Kairui Song <kasong@xxxxxxxxxx>
arch/x86/kernel/kexec-bzimage64.c | 21 +++++++++++++++++++++
drivers/acpi/acpica/tbxfroot.c | 3 +--
include/acpi/acpixf.h | 2 +-
3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 53917a3ebf94..0a90dcbd041f 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -20,6 +20,7 @@
#include <linux/mm.h>
#include <linux/efi.h>
#include <linux/verification.h>
+#include <linux/acpi.h>

#include <asm/bootparam.h>
#include <asm/setup.h>
@@ -255,8 +256,28 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
/* Setup EFI state */
setup_efi_state(params, params_load_addr, efi_map_offset, efi_map_sz,
+ /* Setup ACPI RSDP pointer in case EFI is not available in second kernel */
+ if (!acpi_disabled && (!efi_enabled(EFI_RUNTIME_SERVICES) || efi_enabled(EFI_OLD_MEMMAP))) {
+ /* Copied from acpi_os_get_root_pointer accordingly */
+ params->acpi_rsdp_addr = boot_params.acpi_rsdp_addr;
+ if (!params->acpi_rsdp_addr) {
+ if (efi_enabled(EFI_CONFIG_TABLES)) {
+ 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;
+ acpi_find_root_pointer(&params->acpi_rsdp_addr);
+ }
+ }
+ if (!params->acpi_rsdp_addr)
+ pr_warn("RSDP is not available for second kernel\n");
+ }
Amazing the amount of ACPI RDSP parsing and fiddling patches flying
around these days...

In any case, this needs to be synchronized with:

and checked whether the above can be used instead of sprinkling of ACPI
parsing code left and right.
Both Baoquan and Chao are cced for comments.
The above KASLR patches seems some early code to parsing acpi, but I think in this
patch just call acpi function to get the root pointer no need to add the
duplicate logic of if/else/else if.

Kairui, do you have any reason for the checking? Is there some simple
acpi function to just return the root pointer?
Hi, I'm afraid that would require moving multiple structure and
function out of .init,
acpi_os_get_root_pointer is an ideal function to do the job, but it's
in .init and (on x86) it will call x86_init.acpi.get_root_pointer (by
calling acpi_arch_get_root_pointer) which will also be freed after
init, unless I change the x86_init, move they out of .init which is
not a good idea.

Maybe I could split acpi_os_get_root_pointer into two, one gets freed
after init, one for later use. But the "acpi_rsdp_addr" trick only
works for x86, and this would change more common acpi driver code so
not sure if a good idea.
Can the acpi root pointer be saved after initialized? If that is good
then a new function to get it would be easier. But need opinion from
acpi people.

For that, please repost the series with a CC to linux-acpi@xxxxxxxxxxxxxxxx