All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Kairui Song <kasong@redhat.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, x86@kernel.org,
	dyoung@redhat.com, bhe@redhat.com, kexec@lists.infradead.org,
	akpm@linux-foundation.org, robert.moore@intel.com,
	erik.schmauss@intel.com, rafael.j.wysocki@intel.com,
	lenb@kernel.org
Subject: Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
Date: Wed, 16 Jan 2019 00:10:05 +0100	[thread overview]
Message-ID: <20190115231005.GF6596@zn.tnic> (raw)
In-Reply-To: <20190115095834.22617-3-kasong@redhat.com>

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@redhat.com>
> Signed-off-by: Kairui Song <kasong@redhat.com>
> ---
>  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,
>  			efi_setup_data_offset);
> +
> +#ifdef CONFIG_ACPI
> +	/* 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;
> +			} else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> +				acpi_find_root_pointer(&params->acpi_rsdp_addr);
> +			}
> +		}
> +		if (!params->acpi_rsdp_addr)
> +			pr_warn("RSDP is not available for second kernel\n");
> +	}
>  #endif

Amazing the amount of ACPI RDSP parsing and fiddling patches flying
around these days...

In any case, this needs to be synchronized with:

https://lkml.kernel.org/r/20190107032243.25324-1-fanc.fnst@cn.fujitsu.com

and checked whether the above can be used instead of sprinkling of ACPI
parsing code left and right.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Kairui Song <kasong@redhat.com>
Cc: rafael.j.wysocki@intel.com, bhe@redhat.com,
	erik.schmauss@intel.com, x86@kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	robert.moore@intel.com, mingo@redhat.com, hpa@zytor.com,
	tglx@linutronix.de, dyoung@redhat.com, akpm@linux-foundation.org,
	lenb@kernel.org
Subject: Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
Date: Wed, 16 Jan 2019 00:10:05 +0100	[thread overview]
Message-ID: <20190115231005.GF6596@zn.tnic> (raw)
In-Reply-To: <20190115095834.22617-3-kasong@redhat.com>

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@redhat.com>
> Signed-off-by: Kairui Song <kasong@redhat.com>
> ---
>  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,
>  			efi_setup_data_offset);
> +
> +#ifdef CONFIG_ACPI
> +	/* 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;
> +			} else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> +				acpi_find_root_pointer(&params->acpi_rsdp_addr);
> +			}
> +		}
> +		if (!params->acpi_rsdp_addr)
> +			pr_warn("RSDP is not available for second kernel\n");
> +	}
>  #endif

Amazing the amount of ACPI RDSP parsing and fiddling patches flying
around these days...

In any case, this needs to be synchronized with:

https://lkml.kernel.org/r/20190107032243.25324-1-fanc.fnst@cn.fujitsu.com

and checked whether the above can be used instead of sprinkling of ACPI
parsing code left and right.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2019-01-15 23:10 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15  9:58 [PATCH 0/2] make kexec work with efi=noruntime or efi=old_map Kairui Song
2019-01-15  9:58 ` Kairui Song
2019-01-15  9:58 ` [PATCH v2 1/2] x86, kexec_file_load: Don't setup EFI info if EFI runtime is not enabled Kairui Song
2019-01-15  9:58   ` Kairui Song
2019-01-15  9:58 ` [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map Kairui Song
2019-01-15  9:58   ` Kairui Song
2019-01-15 23:10   ` Borislav Petkov [this message]
2019-01-15 23:10     ` Borislav Petkov
2019-01-16  3:32     ` Dave Young
2019-01-16  3:32       ` Dave Young
2019-01-16  5:09       ` Kairui Song
2019-01-16  5:09         ` Kairui Song
2019-01-16  6:51         ` Dave Young
2019-01-16  6:51           ` Dave Young
2019-01-16 22:24           ` Rafael J. Wysocki
2019-01-16 22:24             ` Rafael J. Wysocki
2019-01-16  7:08     ` Kairui Song
2019-01-16  7:08       ` Kairui Song
2019-01-16  9:46       ` Borislav Petkov
2019-01-16  9:46         ` Borislav Petkov
2019-01-17  7:41         ` Kairui Song
2019-01-17  7:41           ` Kairui Song
2019-01-17  7:49           ` Chao Fan
2019-01-17  7:49             ` Chao Fan
2019-01-17  8:20             ` Kairui Song
2019-01-17  8:20               ` Kairui Song
2019-01-17  8:54             ` Dave Young
2019-01-17  8:54               ` Dave Young
2019-01-17  8:53           ` Dave Young
2019-01-17  8:53             ` Dave Young
2019-01-17  9:39             ` Rafael J. Wysocki
2019-01-17  9:39               ` Rafael J. Wysocki
2019-01-18  4:47               ` Kairui Song
2019-01-18  4:47                 ` Kairui Song
2019-01-18  9:45                 ` Rafael J. Wysocki
2019-01-18  9:45                   ` Rafael J. Wysocki
2019-01-18 10:26           ` Borislav Petkov
2019-01-18 10:26             ` Borislav Petkov
2019-01-21  1:18             ` Chao Fan
2019-01-21  1:18               ` Chao Fan
2019-01-21  8:29               ` Borislav Petkov
2019-01-21  8:29                 ` Borislav Petkov
2019-01-21  8:43                 ` Chao Fan
2019-01-21  8:43                   ` Chao Fan
2019-01-21  9:19                   ` Borislav Petkov
2019-01-21  9:19                     ` Borislav Petkov
2019-01-22  3:32                 ` Chao Fan
2019-01-22  3:32                   ` Chao Fan
2019-01-22 12:17                   ` Borislav Petkov
2019-01-22 12:17                     ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190115231005.GF6596@zn.tnic \
    --to=bp@alien8.de \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=erik.schmauss@intel.com \
    --cc=hpa@zytor.com \
    --cc=kasong@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robert.moore@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.