All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Chao Fan <fanc.fnst@cn.fujitsu.com>
Cc: Kairui Song <kasong@redhat.com>, 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>,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH v2 2/2] x86, kexec_file_load: make it work with efi=noruntime or efi=old_map
Date: Thu, 17 Jan 2019 16:54:06 +0800	[thread overview]
Message-ID: <20190117085406.GB17940@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20190117074959.GB31097@localhost.localdomain>

+ linux-acpi list
On 01/17/19 at 03:49pm, Chao Fan wrote:
> On Thu, Jan 17, 2019 at 03:41:13PM +0800, Kairui Song wrote:
> >On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov <bp@alien8.de> wrote:
> >>
> >> On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> >> > I didn't see a way to reuse things in that patch series, situation is
> >> > different, in that patch it needs to get RSDP in very early boot stage
> >> > so it did everything from scratch, in this patch kexec_file_load need
> >> > to get RSDP too, but everything is well setup so things are a lot
> >> > easier, just read from current boot_prams, efi and fallback to
> >> > acpi_find_root_pointer should be good.
> >>
> >> No no. Early code should find out that venerable RSDP thing once and
> >> will save it somewhere for further use. No gazillion parsings of it.
> >> Just once and share it with the rest of the code that needs it.
> >>
> >
> >How about we refill the boot_params.acpi_rsdp_addr if it is not valid
> >in early code, so it could be used as a reliable RSDP address source?
> >That should make things easier.
> 
> I think it's OK.
> Try to read it, if get RSDP, use it.
> If not, search in EFI/BIOS/... and refill the RSDP to
> boot_params.acpi_rsdp_addr.
> By the way, I search kernel code, I didn't find other code fill and
> use it, only you(KEXEC) are trying to fill it.
> If I miss something, please let me know.
> 
> Thanks,
> Chao Fan
> 
> >
> >But if early code should parse it and store it should be done in
> >Chao's patch, or I can post another patch to do it if Chao's patch is
> >merged.
> >
> >For now I think good to have something like this in this patch series
> >to always keep storing acpi_rsdp in late code,
> >acpi_os_get_root_pointer_late (maybe comeup with a better name later)
> >could be used anytime to get RSDP and no extra parsing:
> >
> >--- a/drivers/acpi/osl.c
> >+++ b/drivers/acpi/osl.c
> >@@ -180,8 +180,8 @@ void acpi_os_vprintf(const char *fmt, va_list args)
> > #endif
> > }
> >
> >-#ifdef CONFIG_KEXEC
> > static unsigned long acpi_rsdp;
> >+#ifdef CONFIG_KEXEC
> > static int __init setup_acpi_rsdp(char *arg)
> > {
> >        return kstrtoul(arg, 16, &acpi_rsdp);
> >@@ -189,28 +189,38 @@ static int __init setup_acpi_rsdp(char *arg)
> > early_param("acpi_rsdp", setup_acpi_rsdp);
> > #endif
> >
> >+acpi_physical_address acpi_os_get_root_pointer_late(void) {
> >+       return acpi_rsdp;
> >+}
> >+
> > acpi_physical_address __init acpi_os_get_root_pointer(void)
> > {
> >        acpi_physical_address pa;
> >
> >-#ifdef CONFIG_KEXEC
> >        if (acpi_rsdp)
> >                return acpi_rsdp;
> >-#endif
> >+
> >        pa = acpi_arch_get_root_pointer();
> >-       if (pa)
> >+       if (pa) {
> >+               acpi_rsdp = pa;
> >                return pa;
> >+       }
> >
> >        if (efi_enabled(EFI_CONFIG_TABLES)) {
> >-               if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> >+               if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) {
> >+                       acpi_rsdp = efi.acpi20;
> >                        return efi.acpi20;
> >-               if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> >+               }
> >+               if (efi.acpi != EFI_INVALID_TABLE_ADDR) {
> >+                       acpi_rsdp = efi.acpi;
> >                        return efi.acpi;
> >+               }
> >                pr_err(PREFIX "System description tables not found\n");
> >        } else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> >                acpi_find_root_pointer(&pa);
> >        }
> >
> > +       acpi_rsdp = pa;
> >        return pa;
> > }
> >
> >> --
> >> Regards/Gruss,
> >>     Boris.
> >>
> >> Good mailing practices for 400: avoid top-posting and trim the reply.
> >--
> >Best Regards,
> >Kairui Song
> >
> >
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung@redhat.com>
To: Chao Fan <fanc.fnst@cn.fujitsu.com>
Cc: rafael.j.wysocki@intel.com, Kairui Song <kasong@redhat.com>,
	Baoquan He <bhe@redhat.com>,
	x86@kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, robert.moore@intel.com,
	linux-acpi@vger.kernel.org, mingo@redhat.com,
	Borislav Petkov <bp@alien8.de>,
	hpa@zytor.com, tglx@linutronix.de, erik.schmauss@intel.com,
	akpm@linux-foundation.org, 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: Thu, 17 Jan 2019 16:54:06 +0800	[thread overview]
Message-ID: <20190117085406.GB17940@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20190117074959.GB31097@localhost.localdomain>

+ linux-acpi list
On 01/17/19 at 03:49pm, Chao Fan wrote:
> On Thu, Jan 17, 2019 at 03:41:13PM +0800, Kairui Song wrote:
> >On Wed, Jan 16, 2019 at 5:46 PM Borislav Petkov <bp@alien8.de> wrote:
> >>
> >> On Wed, Jan 16, 2019 at 03:08:42PM +0800, Kairui Song wrote:
> >> > I didn't see a way to reuse things in that patch series, situation is
> >> > different, in that patch it needs to get RSDP in very early boot stage
> >> > so it did everything from scratch, in this patch kexec_file_load need
> >> > to get RSDP too, but everything is well setup so things are a lot
> >> > easier, just read from current boot_prams, efi and fallback to
> >> > acpi_find_root_pointer should be good.
> >>
> >> No no. Early code should find out that venerable RSDP thing once and
> >> will save it somewhere for further use. No gazillion parsings of it.
> >> Just once and share it with the rest of the code that needs it.
> >>
> >
> >How about we refill the boot_params.acpi_rsdp_addr if it is not valid
> >in early code, so it could be used as a reliable RSDP address source?
> >That should make things easier.
> 
> I think it's OK.
> Try to read it, if get RSDP, use it.
> If not, search in EFI/BIOS/... and refill the RSDP to
> boot_params.acpi_rsdp_addr.
> By the way, I search kernel code, I didn't find other code fill and
> use it, only you(KEXEC) are trying to fill it.
> If I miss something, please let me know.
> 
> Thanks,
> Chao Fan
> 
> >
> >But if early code should parse it and store it should be done in
> >Chao's patch, or I can post another patch to do it if Chao's patch is
> >merged.
> >
> >For now I think good to have something like this in this patch series
> >to always keep storing acpi_rsdp in late code,
> >acpi_os_get_root_pointer_late (maybe comeup with a better name later)
> >could be used anytime to get RSDP and no extra parsing:
> >
> >--- a/drivers/acpi/osl.c
> >+++ b/drivers/acpi/osl.c
> >@@ -180,8 +180,8 @@ void acpi_os_vprintf(const char *fmt, va_list args)
> > #endif
> > }
> >
> >-#ifdef CONFIG_KEXEC
> > static unsigned long acpi_rsdp;
> >+#ifdef CONFIG_KEXEC
> > static int __init setup_acpi_rsdp(char *arg)
> > {
> >        return kstrtoul(arg, 16, &acpi_rsdp);
> >@@ -189,28 +189,38 @@ static int __init setup_acpi_rsdp(char *arg)
> > early_param("acpi_rsdp", setup_acpi_rsdp);
> > #endif
> >
> >+acpi_physical_address acpi_os_get_root_pointer_late(void) {
> >+       return acpi_rsdp;
> >+}
> >+
> > acpi_physical_address __init acpi_os_get_root_pointer(void)
> > {
> >        acpi_physical_address pa;
> >
> >-#ifdef CONFIG_KEXEC
> >        if (acpi_rsdp)
> >                return acpi_rsdp;
> >-#endif
> >+
> >        pa = acpi_arch_get_root_pointer();
> >-       if (pa)
> >+       if (pa) {
> >+               acpi_rsdp = pa;
> >                return pa;
> >+       }
> >
> >        if (efi_enabled(EFI_CONFIG_TABLES)) {
> >-               if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
> >+               if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) {
> >+                       acpi_rsdp = efi.acpi20;
> >                        return efi.acpi20;
> >-               if (efi.acpi != EFI_INVALID_TABLE_ADDR)
> >+               }
> >+               if (efi.acpi != EFI_INVALID_TABLE_ADDR) {
> >+                       acpi_rsdp = efi.acpi;
> >                        return efi.acpi;
> >+               }
> >                pr_err(PREFIX "System description tables not found\n");
> >        } else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
> >                acpi_find_root_pointer(&pa);
> >        }
> >
> > +       acpi_rsdp = pa;
> >        return pa;
> > }
> >
> >> --
> >> Regards/Gruss,
> >>     Boris.
> >>
> >> Good mailing practices for 400: avoid top-posting and trim the reply.
> >--
> >Best Regards,
> >Kairui Song
> >
> >
> 
> 

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

  parent reply	other threads:[~2019-01-17  8:54 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
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 [this message]
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=20190117085406.GB17940@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-acpi@vger.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.