All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Kairui Song <kasong@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, x86@kernel.org,
	Baoquan He <bhe@redhat.com>,
	kexec@lists.infradead.org, akpm@linux-foundation.org,
	robert.moore@intel.com, erik.schmauss@intel.com,
	rafael.j.wysocki@intel.com, Len Brown <lenb@kernel.org>,
	Chao Fan <fanc.fnst@cn.fujitsu.com>
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 14:51:26 +0800	[thread overview]
Message-ID: <20190116065126.GC6468@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <CACPcB9fWoV=b3DwhmBAAgqDHc0x=PfSyEuqnZcAQjM=LLLkAQw@mail.gmail.com>

On 01/16/19 at 01:09pm, Kairui Song wrote:
> On Wed, Jan 16, 2019 at 11:32 AM Dave Young <dyoung@redhat.com> 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@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.
> >
> > 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.

Thanks
Dave

WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung@redhat.com>
To: Kairui Song <kasong@redhat.com>
Cc: rafael.j.wysocki@intel.com, Baoquan He <bhe@redhat.com>,
	x86@kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, robert.moore@intel.com,
	mingo@redhat.com, Borislav Petkov <bp@alien8.de>,
	hpa@zytor.com, tglx@linutronix.de, erik.schmauss@intel.com,
	akpm@linux-foundation.org, Chao Fan <fanc.fnst@cn.fujitsu.com>,
	Len Brown <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 14:51:26 +0800	[thread overview]
Message-ID: <20190116065126.GC6468@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <CACPcB9fWoV=b3DwhmBAAgqDHc0x=PfSyEuqnZcAQjM=LLLkAQw@mail.gmail.com>

On 01/16/19 at 01:09pm, Kairui Song wrote:
> On Wed, Jan 16, 2019 at 11:32 AM Dave Young <dyoung@redhat.com> 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@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.
> >
> > 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.

Thanks
Dave

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

  reply	other threads:[~2019-01-16  6:51 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
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 [this message]
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=20190116065126.GC6468@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=erik.schmauss@intel.com \
    --cc=fanc.fnst@cn.fujitsu.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.