Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1542648 > unrolled thread

Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to  kexec'ed kernel Jean Delvare <jdelvare@suse.de> - 2016-12-15 12:30 +0100
    Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to  kexec'ed kernel Dave Young <dyoung@redhat.com> - 2016-12-16 03:40 +0100
      Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to  kexec'ed kernel Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-12-16 13:30 +0100
        Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to  kexec'ed kernel Jean Delvare <jdelvare@suse.de> - 2016-12-16 14:40 +0100
          Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to  kexec'ed kernel Dave Young <dyoung@redhat.com> - 2016-12-17 12:00 +0100
        Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to  kexec'ed kernel Dave Young <dyoung@redhat.com> - 2016-12-17 12:00 +0100

#1542648 — Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel

Hi Andy,

On Fri,  2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote:
> Until now kexec'ed kernel has no clue where to look for DMI entry point.
> 
> Pass it via kernel command line parameter in the same way as it's done for ACPI
> RSDP.

I am no kexec expert but this confuses me. Shouldn't the second kernel
have access to the EFI systab as the first kernel does? It includes
many more pointers than just ACPI and DMI tables, and it would seem
inconvenient to have to pass all these addresses individually
explicitly.

Adding Eric to Cc for his opinion.

> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  5 +++++
>  drivers/firmware/dmi_scan.c                     | 14 ++++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index be2d6d0..94f219f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -843,6 +843,11 @@
>  			The filter can be disabled or changed to another
>  			driver later using sysfs.
>  
> +	dmi_entry_point=	[DMI,EFI,KEXEC]
> +			Pass the DMI entry point to the kernel, mostly used
> +			on machines running EFI runtime service to boot the
> +			second kernel for kdump.
> +
>  	drm_kms_helper.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]
>  			Broken monitors, graphic adapters, KVMs and EDIDless
>  			panels may send no or incorrect EDID data sets.
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index b88def6..215843f 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -595,8 +595,22 @@ static int __init dmi_smbios3_present(const u8 *buf)
>  	return 1;
>  }
>  
> +#ifdef CONFIG_KEXEC
> +static unsigned long dmi_entry_point;
> +static int __init setup_dmi_entry_point(char *arg)
> +{
> +	return kstrtoul(arg, 16, &dmi_entry_point);
> +}
> +early_param("dmi_entry_point", setup_dmi_entry_point);
> +#endif
> +
>  static resource_size_t __init dmi_get_entry_point(void)
>  {
> +#ifdef CONFIG_KEXEC
> +	if (dmi_entry_point)
> +		return dmi_entry_point;
> +#endif
> +
>  	if (efi_enabled(EFI_CONFIG_TABLES)) {
>  		/*
>  		 * According to the DMTF SMBIOS reference spec v3.0.0, it is


-- 
Jean Delvare
SUSE L3 Support

[toc] | [next] | [standalone]

#1543184

On 12/15/16 at 12:28pm, Jean Delvare wrote:
> Hi Andy,
> 
> On Fri,  2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote:
> > Until now kexec'ed kernel has no clue where to look for DMI entry point.
> > 
> > Pass it via kernel command line parameter in the same way as it's done for ACPI
> > RSDP.
> 
> I am no kexec expert but this confuses me. Shouldn't the second kernel
> have access to the EFI systab as the first kernel does? It includes
> many more pointers than just ACPI and DMI tables, and it would seem
> inconvenient to have to pass all these addresses individually
> explicitly.

Yes, in modern linux kernel, kexec has the support for EFI, I think it
should work naturally at least in x86_64.

Is there any test log with latest mainline kernel about this?

> 
> Adding Eric to Cc for his opinion.
> 
> > 
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |  5 +++++
> >  drivers/firmware/dmi_scan.c                     | 14 ++++++++++++++
> >  2 files changed, 19 insertions(+)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index be2d6d0..94f219f 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -843,6 +843,11 @@
> >  			The filter can be disabled or changed to another
> >  			driver later using sysfs.
> >  
> > +	dmi_entry_point=	[DMI,EFI,KEXEC]
> > +			Pass the DMI entry point to the kernel, mostly used
> > +			on machines running EFI runtime service to boot the
> > +			second kernel for kdump.
> > +
> >  	drm_kms_helper.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]
> >  			Broken monitors, graphic adapters, KVMs and EDIDless
> >  			panels may send no or incorrect EDID data sets.
> > diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> > index b88def6..215843f 100644
> > --- a/drivers/firmware/dmi_scan.c
> > +++ b/drivers/firmware/dmi_scan.c
> > @@ -595,8 +595,22 @@ static int __init dmi_smbios3_present(const u8 *buf)
> >  	return 1;
> >  }
> >  
> > +#ifdef CONFIG_KEXEC
> > +static unsigned long dmi_entry_point;
> > +static int __init setup_dmi_entry_point(char *arg)
> > +{
> > +	return kstrtoul(arg, 16, &dmi_entry_point);
> > +}
> > +early_param("dmi_entry_point", setup_dmi_entry_point);
> > +#endif
> > +
> >  static resource_size_t __init dmi_get_entry_point(void)
> >  {
> > +#ifdef CONFIG_KEXEC
> > +	if (dmi_entry_point)
> > +		return dmi_entry_point;
> > +#endif
> > +
> >  	if (efi_enabled(EFI_CONFIG_TABLES)) {
> >  		/*
> >  		 * According to the DMTF SMBIOS reference spec v3.0.0, it is
> 
> 
> -- 
> Jean Delvare
> SUSE L3 Support
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

[toc] | [prev] | [next] | [standalone]

#1543425

On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > Hi Andy,
> > 
> > On Fri,  2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote:
> > > Until now kexec'ed kernel has no clue where to look for DMI entry
> > > point.
> > > 
> > > Pass it via kernel command line parameter in the same way as it's
> > > done for ACPI
> > > RSDP.
> > 
> > I am no kexec expert but this confuses me. Shouldn't the second
> > kernel
> > have access to the EFI systab as the first kernel does? It includes
> > many more pointers than just ACPI and DMI tables, and it would seem
> > inconvenient to have to pass all these addresses individually
> > explicitly.
> 
> Yes, in modern linux kernel, kexec has the support for EFI, I think it
> should work naturally at least in x86_64.

Thanks for this good news!

Unfortunately Intel Galileo is 32-bit platform.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1543464

On Fri, 16 Dec 2016 14:18:58 +0200, Andy Shevchenko wrote:
> On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> > On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > > I am no kexec expert but this confuses me. Shouldn't the second
> > > kernel have access to the EFI systab as the first kernel does? It
> > > includes many more pointers than just ACPI and DMI tables, and it
> > > would seem inconvenient to have to pass all these addresses
> > > individually explicitly.
> > 
> > Yes, in modern linux kernel, kexec has the support for EFI, I think it
> > should work naturally at least in x86_64.
> 
> Thanks for this good news!
> 
> Unfortunately Intel Galileo is 32-bit platform.

If it was done for X86_64 then maybe it can be generalized to X86?

-- 
Jean Delvare
SUSE L3 Support

[toc] | [prev] | [next] | [standalone]

#1543952

Ccing efi people.

On 12/16/16 at 02:33pm, Jean Delvare wrote:
> On Fri, 16 Dec 2016 14:18:58 +0200, Andy Shevchenko wrote:
> > On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> > > On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > > > I am no kexec expert but this confuses me. Shouldn't the second
> > > > kernel have access to the EFI systab as the first kernel does? It
> > > > includes many more pointers than just ACPI and DMI tables, and it
> > > > would seem inconvenient to have to pass all these addresses
> > > > individually explicitly.
> > > 
> > > Yes, in modern linux kernel, kexec has the support for EFI, I think it
> > > should work naturally at least in x86_64.
> > 
> > Thanks for this good news!
> > 
> > Unfortunately Intel Galileo is 32-bit platform.
> 
> If it was done for X86_64 then maybe it can be generalized to X86?

For X86_64, we have a new way for efi runtime memmory mapping, in i386
code it still use old ioremap way. It is impossible to use same way as
the X86_64 since the virtual address space is limited.

But maybe for 32bit, kexec kernel can run in physical mode, but I'm not
sure, I would suggest Andy to do a test first with efi=noruntime for
kexec 2nd kernel.

Thanks
Dave

> 
> -- 
> Jean Delvare
> SUSE L3 Support

[toc] | [prev] | [next] | [standalone]

#1543953

On 12/16/16 at 02:18pm, Andy Shevchenko wrote:
> On Fri, 2016-12-16 at 10:32 +0800, Dave Young wrote:
> > On 12/15/16 at 12:28pm, Jean Delvare wrote:
> > > Hi Andy,
> > > 
> > > On Fri,  2 Dec 2016 21:54:16 +0200, Andy Shevchenko wrote:
> > > > Until now kexec'ed kernel has no clue where to look for DMI entry
> > > > point.
> > > > 
> > > > Pass it via kernel command line parameter in the same way as it's
> > > > done for ACPI
> > > > RSDP.
> > > 
> > > I am no kexec expert but this confuses me. Shouldn't the second
> > > kernel
> > > have access to the EFI systab as the first kernel does? It includes
> > > many more pointers than just ACPI and DMI tables, and it would seem
> > > inconvenient to have to pass all these addresses individually
> > > explicitly.
> > 
> > Yes, in modern linux kernel, kexec has the support for EFI, I think it
> > should work naturally at least in x86_64.
> 
> Thanks for this good news!
> 
> Unfortunately Intel Galileo is 32-bit platform.

Maybe you can try use efi=noruntime kernel parameter in kexec/kdump
kernel, see if it works or not.

> 
> -- 
> Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Intel Finland Oy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web