Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel
On Tue, Jan 21, 2020 at 11:17:19AM -0600, Eric W. Biederman wrote: > Andy Shevchenko writes: > > On Tue, Jan 21, 2020 at 12:18:03AM +0100, Ard Biesheuvel wrote: > >> On Mon, 20 Jan 2020 at 23:31, Andy Shevchenko > >> wrote: > >> > On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman > >> > wrote: > >> > > Andy Shevchenko writes: > >> > > > On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote: ... > >> > > > Can we apply these patches for now until you will find better > >> > > > solution? > >> > > > >> > > Not a chance. The patches don't apply to any kernel in the git > >> > > history. > >> > > > >> > > Which may be part of your problem. You are or at least were running > >> > > with code that has not been merged upstream. > >> > > >> > It's done against linux-next. > >> > Applied clearly. (Not the version in this more than yearly old series > >> > of course, that's why I told I can resend) > >> > > >> > > > P.S. I may resend them rebased on recent vanilla. > >> > > > >> > > Second. I looked at your test results and they don't directly make > >> > > sense. dmidecode bypasses the kernel completely or it did last time > >> > > I looked so I don't know why you would be using that to test if > >> > > something in the kernel is working. > >> > > > >> > > However dmidecode failing suggests that the actual problem is something > >> > > in the first kernel is stomping the dmi tables. > >> > > >> > See below. > >> > > >> > > Adding a command line option won't fix stomped tables. > >> > > >> > It provides a mechanism, which seems to be absent, to the second > >> > kernel to know where to look for SMBIOS tables. > >> > > >> > > So what I would suggest is: > >> > > a) Verify that dmidecode works before kexec. > >> > > >> > Yes, it does. > >> > > >> > > b) Test to see if dmidecode works after kexec. > >> > > >> > No, it doesn't. > >> > > >> > > c) Once (a) shows that dmidecode works and (b) shows that dmidecode > >> > >fails figure out what is stomping your dmi tables during or before > >> > >kexec and that is what should get fixed. > >> > > >> > The problem here as I can see it that EFI and kexec protocols are not > >> > friendly to each other. > >> > I'm not an expert in either. That's why I'm asking for possible > >> > solutions. And this needs to be done in kernel to allow drivers to > >> > work. > >> > > >> > Does the > >> > > >> > commit 4996c02306a25def1d352ec8e8f48895bbc7dea9 > >> > Author: Takao Indoh > >> > Date: Thu Jul 14 18:05:21 2011 -0400 > >> > > >> > ACPI: introduce "acpi_rsdp=" parameter for kdump > >> > > >> > description shed a light on this? > >> > > >> > > Now using a non-efi method of dmi detection relies on the > >> > > tables being between 0xF and 0x1. AKA the last 64K > >> > > of the first 1MiB of memory. You might check to see if your > >> > > dmi tables are in that address range. > >> > > >> > # dmidecode --no-sysfs > >> > # dmidecode 3.2 > >> > Scanning /dev/mem for entry point. > >> > # No SMBIOS nor DMI entry point found, sorry. > >> > > >> > === with patch applied === > >> > # dmidecode > >> > ... > >> > Release Date: 03/10/2015 > >> > ... > >> > > >> > > > >> > > Otherwise I suspect the good solution is to give efi it's own page > >> > > tables in the kernel and switch to it whenever efi functions are > >> > > called. > >> > > > >> > > >> > > But on 32bit the Linux kernel has historically been just fine directly > >> > > accessing the hardware, and ignoring efi and all of the other BIOS's. > >> > > >> > It seems not only for 32-bit Linux kernel anymore. MS Surface 3 runs > >> > 64-bit code. > >> > > >> > > So if that doesn't work on Intel Galileo that is probably a firmware > >> > > problem. > >> > > >> > It's not only about Galileo anymore. > >> > > >> > >> Looking at the x86 kexec EFI code, it seems that it has special > >> handling for the legacy SMBIOS table address, but not for the SMBIOS3 > >> table address, which was introduced to accommodate SMBIOS tables > >> living in memory that is not 32-bit addressable. > >> > >> Could anyone check whether these systems provide SMBIOS 3.0 tables, > >> and whether their address gets virtually remapped at ExitBootServices? > > > > On Microsoft Surface 3 tablet: > > > > === First kernel === > > > > # uname -a > > > > (Previously reported issue on) > > Linux buildroot 4.13.0+ #39 SMP Tue Sep 5 14:58:23 EEST 2017 x86_64 > > GNU/Linux > > > > (Updated today to) > > Linux buildroot 5.4.0+ #2 SMP Tue Nov 26 15:36:31 EET 2019 x86_64 GNU/Linux > > > > # ls -l /sys/firmware/dmi/tables/ > > total 0 > > -r1 root root 825 Jan 21 15:41 DMI > > -r1 root root31 Jan 21 15:41 smbios_entry_point > > > > # od -Ax -tx1 /sys/firmware/dmi/tables/smbios_entry_point > > 00 5f 53 4d 5f 0f 1f 02 08 6a 00 00 00 00 00 00 00 > > 10 5f 44 4d 49 5f e0 39 03 00 40 5b 7b 0f 00 27 > > 1f > > > > # dmesg | grep -i dmi > > [0.00] DMI: Microsoft Corporati
Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel
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
Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel
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 > Intel Finland Oy
Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel
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
Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel
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 Intel Finland Oy
Re: [PATCH v1 2/2] firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel
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
> > ---
> > 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=[:][,[:]]
> > 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
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
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
> ---
> 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=[:][,[:]]
> 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
