Until now DMI information is lost when kexec'ing. Fix this in the same way as
it has been done for ACPI RSDP.
Series has been tested on Galileo Gen2 where DMI is used by drivers, in
particular the default I2C host speed is choosen based on DMI system
information and now gets it correct.
Andy Shevchenko (2):
firmware: dmi_scan: Split out dmi_get_entry_point() helper
firmware: dmi_scan: Pass dmi_entry_point to kexec'ed kernel
Documentation/admin-guide/kernel-parameters.txt | 5 +++
drivers/firmware/dmi_scan.c | 49 +++++++++++++++----------
2 files changed, 35 insertions(+), 19 deletions(-)
--
2.10.2
This is preparatory patch to pass DMI entry point to kexec'ed kernel.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/firmware/dmi_scan.c | 37 +++++++++++++++++--------------------
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 88bebe1..b88def6 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -595,11 +595,8 @@ static int __init dmi_smbios3_present(const u8 *buf)
return 1;
}
-void __init dmi_scan_machine(void)
+static resource_size_t __init dmi_get_entry_point(void)
{
- char __iomem *p, *q;
- char buf[32];
-
if (efi_enabled(EFI_CONFIG_TABLES)) {
/*
* According to the DMTF SMBIOS reference spec v3.0.0, it is
@@ -614,32 +611,32 @@ void __init dmi_scan_machine(void)
* have the 64-bit entry point, but fail to decode it, fall
* back to the legacy one (if available)
*/
- if (efi.smbios3 != EFI_INVALID_TABLE_ADDR) {
- p = dmi_early_remap(efi.smbios3, 32);
- if (p == NULL)
- goto error;
- memcpy_fromio(buf, p, 32);
- dmi_early_unmap(p, 32);
-
- if (!dmi_smbios3_present(buf)) {
- dmi_available = 1;
- goto out;
- }
- }
- if (efi.smbios == EFI_INVALID_TABLE_ADDR)
- goto error;
+ if (efi.smbios3 != EFI_INVALID_TABLE_ADDR)
+ return efi.smbios3;
+ if (efi.smbios != EFI_INVALID_TABLE_ADDR)
+ return efi.smbios;
+ }
+ return 0;
+}
+
+void __init dmi_scan_machine(void)
+{
+ resource_size_t ep = dmi_get_entry_point();
+ char __iomem *p, *q;
+ char buf[32];
+ if (ep) {
/* This is called as a core_initcall() because it isn't
* needed during early boot. This also means we can
* iounmap the space when we're done with it.
*/
- p = dmi_early_remap(efi.smbios, 32);
+ p = dmi_early_remap(ep, 32);
if (p == NULL)
goto error;
memcpy_fromio(buf, p, 32);
dmi_early_unmap(p, 32);
- if (!dmi_present(buf)) {
+ if (!dmi_smbios3_present(buf) || !dmi_present(buf)) {
dmi_available = 1;
goto out;
}
--
2.10.2
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.
Signed-off-by: Andy Shevchenko <[email protected]>
---
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
--
2.10.2
Hi Andy,
On Fri, 2 Dec 2016 21:54:15 +0200, Andy Shevchenko wrote:
> This is preparatory patch to pass DMI entry point to kexec'ed kernel.
You are doing more than that. You are actually changing the logic.
There is this comment in the code:
* [...] If we
* have the 64-bit entry point, but fail to decode it, fall
* back to the legacy one (if available)
The original code was doing that, but your code does not. You will
select one entry point, try to decode it, and if it fails, there is no
fallback. dmi_present(buf) is not realistically going to succeed in
decoding an SMBIOS 3 entry point, just like dmi_smbios3_present(buf)
has zero chance of success on an SMBIOS 2 entry point. This is merely
wasting CPU cycles without actually providing a fallback solution.
It can be discussed whether this fallback mechanism is mandatory to
keep, but dropping it silently as part of refactoring and leaving the
comment in is not OK.
> Signed-off-by: Andy Shevchenko <[email protected]>
> ---
> drivers/firmware/dmi_scan.c | 37 +++++++++++++++++--------------------
> 1 file changed, 17 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 88bebe1..b88def6 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -595,11 +595,8 @@ static int __init dmi_smbios3_present(const u8 *buf)
> return 1;
> }
>
> -void __init dmi_scan_machine(void)
> +static resource_size_t __init dmi_get_entry_point(void)
I would like this function to have "efi" in its name, as it is
EFI-specific.
> {
> - char __iomem *p, *q;
> - char buf[32];
> -
> if (efi_enabled(EFI_CONFIG_TABLES)) {
> /*
> * According to the DMTF SMBIOS reference spec v3.0.0, it is
> @@ -614,32 +611,32 @@ void __init dmi_scan_machine(void)
> * have the 64-bit entry point, but fail to decode it, fall
> * back to the legacy one (if available)
> */
> - if (efi.smbios3 != EFI_INVALID_TABLE_ADDR) {
> - p = dmi_early_remap(efi.smbios3, 32);
> - if (p == NULL)
> - goto error;
> - memcpy_fromio(buf, p, 32);
> - dmi_early_unmap(p, 32);
> -
> - if (!dmi_smbios3_present(buf)) {
> - dmi_available = 1;
> - goto out;
> - }
> - }
> - if (efi.smbios == EFI_INVALID_TABLE_ADDR)
> - goto error;
> + if (efi.smbios3 != EFI_INVALID_TABLE_ADDR)
> + return efi.smbios3;
> + if (efi.smbios != EFI_INVALID_TABLE_ADDR)
> + return efi.smbios;
> + }
> + return 0;
> +}
> +
> +void __init dmi_scan_machine(void)
> +{
> + resource_size_t ep = dmi_get_entry_point();
Likewise, this variable should have "efi" in its name.
> + char __iomem *p, *q;
> + char buf[32];
>
> + if (ep) {
> /* This is called as a core_initcall() because it isn't
> * needed during early boot. This also means we can
> * iounmap the space when we're done with it.
> */
> - p = dmi_early_remap(efi.smbios, 32);
> + p = dmi_early_remap(ep, 32);
> if (p == NULL)
> goto error;
> memcpy_fromio(buf, p, 32);
> dmi_early_unmap(p, 32);
>
> - if (!dmi_present(buf)) {
> + if (!dmi_smbios3_present(buf) || !dmi_present(buf)) {
> dmi_available = 1;
> goto out;
> }
--
Jean Delvare
SUSE L3 Support
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 <[email protected]>
> ---
> 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
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 <[email protected]>
> > ---
> > 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/kexec
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 <[email protected]>
Intel Finland Oy
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
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 <[email protected]>
> Intel Finland Oy
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
On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote:
> 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.
Sorry for a delay.
Eventually I found time to check this.
Unfortunately the efi=noruntime didn't help:
# uname -a
Linux buildroot 5.3.0-rc7+ #17 Thu Sep 5 16:08:22 EEST 2019 i586 GNU/Linux
# dmidecode
# dmidecode 4.2
Scanning /dev/mem for entry point.
# No SMBIOS nor DMI entry point found, sorry.
#
# cat /proc/cmdline
... ignore_loglevel efi=noruntime earlycon=efifb acpi_rsdp=0xf01e014
So, I am all ears to anything else to try.
--
With Best Regards,
Andy Shevchenko
On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> Until now DMI information is lost when kexec'ing. Fix this in the same way as
> it has been done for ACPI RSDP.
>
> Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> particular the default I2C host speed is choosen based on DMI system
> information and now gets it correct.
Guys, it was quite a long no hear from you.
Today I found that Microsoft Surface 3 also affected by this.
Can we apply these patches for now until you will find better solution?
P.S. I may resend them rebased on recent vanilla.
--
With Best Regards,
Andy Shevchenko
On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote:
> 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.
Guys, it was quite a long no hear from you. As I told you the proposed work
around didn't help. Today I found that Microsoft Surface 3 also affected
by this.
Can we apply these patches for now until you will find better solution?
P.S. I may resend them rebased on recent vanilla.
--
With Best Regards,
Andy Shevchenko
Andy Shevchenko <[email protected]> writes:
> On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote:
>> 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.
>
> Guys, it was quite a long no hear from you. As I told you the proposed work
> around didn't help. Today I found that Microsoft Surface 3 also affected
> by this.
>
> 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.
> 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.
Adding a command line option won't fix stomped tables.
So what I would suggest is:
a) Verify that dmidecode works before kexec.
b) Test to see if dmidecode works after kexec.
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.
Now using a non-efi method of dmi detection relies on the
tables being between 0xF0000 and 0x10000. AKA the last 64K
of the first 1MiB of memory. You might check to see if your
dmi tables are in that address range.
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.
So if that doesn't work on Intel Galileo that is probably a firmware
problem.
Eric
On Mon, 20 Jan 2020 10:04:04 -0600, Eric W. Biederman wrote:
> 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.
That must have been long ago. A recent version of dmidecode (>= 3.0)
running on a recent kernel
(>= d7f96f97c4031fa4ffdb7801f9aae23e96170a6f, v4.2) will read the DMI
data from /sys/firmware/dmi/tables, so it is very much relying on the
kernel doing the right thing. If not, it will still try to fallback to
reading from /dev/mem directly on certain architectures. You can force
that old method with --no-sysfs.
Hope that helps,
--
Jean Delvare
SUSE L3 Support
On Mon, Jan 20, 2020 at 11:44 PM Jean Delvare <[email protected]> wrote:
>
> On Mon, 20 Jan 2020 10:04:04 -0600, Eric W. Biederman wrote:
> > 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.
>
> That must have been long ago. A recent version of dmidecode (>= 3.0)
> running on a recent kernel
> (>= d7f96f97c4031fa4ffdb7801f9aae23e96170a6f, v4.2) will read the DMI
> data from /sys/firmware/dmi/tables, so it is very much relying on the
> kernel doing the right thing. If not, it will still try to fallback to
> reading from /dev/mem directly on certain architectures. You can force
> that old method with --no-sysfs.
>
> Hope that helps,
I don't understand how it possible can help for in-kernel code, like
DMI quirks in a drivers.
--
With Best Regards,
Andy Shevchenko
On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman <[email protected]> wrote:
> Andy Shevchenko <[email protected]> writes:
> > On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote:
> >> 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.
> >
> > Guys, it was quite a long no hear from you. As I told you the proposed work
> > around didn't help. Today I found that Microsoft Surface 3 also affected
> > by this.
> >
> > 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 <[email protected]>
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 0xF0000 and 0x10000. 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.
--
With Best Regards,
Andy Shevchenko
On Mon, 20 Jan 2020 at 23:31, Andy Shevchenko <[email protected]> wrote:
>
> On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman <[email protected]> wrote:
> > Andy Shevchenko <[email protected]> writes:
> > > On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote:
> > >> 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.
> > >
> > > Guys, it was quite a long no hear from you. As I told you the proposed work
> > > around didn't help. Today I found that Microsoft Surface 3 also affected
> > > by this.
> > >
> > > 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 <[email protected]>
> 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 0xF0000 and 0x10000. 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 Mon, 20 Jan 2020 23:55:43 +0200, Andy Shevchenko wrote:
> On Mon, Jan 20, 2020 at 11:44 PM Jean Delvare <[email protected]> wrote:
> >
> > On Mon, 20 Jan 2020 10:04:04 -0600, Eric W. Biederman wrote:
> > > 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.
> >
> > That must have been long ago. A recent version of dmidecode (>= 3.0)
> > running on a recent kernel
> > (>= d7f96f97c4031fa4ffdb7801f9aae23e96170a6f, v4.2) will read the DMI
> > data from /sys/firmware/dmi/tables, so it is very much relying on the
> > kernel doing the right thing. If not, it will still try to fallback to
> > reading from /dev/mem directly on certain architectures. You can force
> > that old method with --no-sysfs.
> >
> > Hope that helps,
>
> I don't understand how it possible can help for in-kernel code, like
> DMI quirks in a drivers.
OK, just ignore me then, probably I misunderstood the point made by
Eric.
--
Jean Delvare
SUSE L3 Support
On Tue, Jan 21, 2020 at 12:18:03AM +0100, Ard Biesheuvel wrote:
> On Mon, 20 Jan 2020 at 23:31, Andy Shevchenko <[email protected]> wrote:
> > On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman <[email protected]> wrote:
> > > Andy Shevchenko <[email protected]> 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 <[email protected]>
> > 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 0xF0000 and 0x10000. 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
-r-------- 1 root root 825 Jan 21 15:41 DMI
-r-------- 1 root root 31 Jan 21 15:41 smbios_entry_point
# od -Ax -tx1 /sys/firmware/dmi/tables/smbios_entry_point
000000 5f 53 4d 5f 0f 1f 02 08 6a 00 00 00 00 00 00 00
000010 5f 44 4d 49 5f e0 39 03 00 40 5b 7b 0f 00 27
00001f
# dmesg | grep -i dmi
[ 0.000000] DMI: Microsoft Corporation Surface 3/Surface 3, BIOS 1.50410.78 03/10/2015
[ 0.403058] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
# dmesg | grep -i smb
[ 0.000000] efi: ESRT=0x7b7c6c98 ACPI=0x7ad5a000 ACPI 2.0=0x7ad5a000 SMBIOS=0x7b5f7d18
[ 0.000000] SMBIOS 2.8 present.
=== kexec'ed kernel ===
# uname -a
(in both cases, see above `uname -a`, the same version)
Linux buildroot 5.5.0-rc7+ #161 SMP Tue Jan 21 15:50:02 EET 2020 x86_64 GNU/Linux
# dmidecode
# dmidecode 3.2
Scanning /dev/mem for entry point.
# No SMBIOS nor DMI entry point found, sorry.
# dmidecode --no-sysfs
# dmidecode 3.2
Scanning /dev/mem for entry point.
# No SMBIOS nor DMI entry point found, sorry.
--
With Best Regards,
Andy Shevchenko
Jean Delvare <[email protected]> writes:
> On Mon, 20 Jan 2020 23:55:43 +0200, Andy Shevchenko wrote:
>> On Mon, Jan 20, 2020 at 11:44 PM Jean Delvare <[email protected]> wrote:
>> >
>> > On Mon, 20 Jan 2020 10:04:04 -0600, Eric W. Biederman wrote:
>> > > 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.
>> >
>> > That must have been long ago. A recent version of dmidecode (>= 3.0)
>> > running on a recent kernel
>> > (>= d7f96f97c4031fa4ffdb7801f9aae23e96170a6f, v4.2) will read the DMI
>> > data from /sys/firmware/dmi/tables, so it is very much relying on the
>> > kernel doing the right thing. If not, it will still try to fallback to
>> > reading from /dev/mem directly on certain architectures. You can force
>> > that old method with --no-sysfs.
>> >
>> > Hope that helps,
>>
>> I don't understand how it possible can help for in-kernel code, like
>> DMI quirks in a drivers.
>
> OK, just ignore me then, probably I misunderstood the point made by
> Eric.
No. I just haven't dived into this area of code in a long time.
It seems a little indirect to use dmidecode as the test to see if the
kernel has the pointer to the dmitables, but with the knowledge you
provided it seems like a perfectly valid test.
Eric
Andy Shevchenko <[email protected]> writes:
> On Tue, Jan 21, 2020 at 12:18:03AM +0100, Ard Biesheuvel wrote:
>> On Mon, 20 Jan 2020 at 23:31, Andy Shevchenko <[email protected]> wrote:
>> > On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman <[email protected]> wrote:
>> > > Andy Shevchenko <[email protected]> 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 <[email protected]>
>> > 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 0xF0000 and 0x10000. 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
> -r-------- 1 root root 825 Jan 21 15:41 DMI
> -r-------- 1 root root 31 Jan 21 15:41 smbios_entry_point
>
> # od -Ax -tx1 /sys/firmware/dmi/tables/smbios_entry_point
> 000000 5f 53 4d 5f 0f 1f 02 08 6a 00 00 00 00 00 00 00
> 000010 5f 44 4d 49 5f e0 39 03 00 40 5b 7b 0f 00 27
> 00001f
>
> # dmesg | grep -i dmi
> [ 0.000000] DMI: Microsoft Corporation Surface 3/Surface 3, BIOS 1.50410.78 03/10/2015
> [ 0.403058] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
>
> # dmesg | grep -i smb
> [ 0.000000] efi: ESRT=0x7b7c6c98 ACPI=0x7ad5a000 ACPI 2.0=0x7ad5a000 SMBIOS=0x7b5f7d18
> [ 0.000000] SMBIOS 2.8 present.
>
> === kexec'ed kernel ===
> # uname -a
> (in both cases, see above `uname -a`, the same version)
> Linux buildroot 5.5.0-rc7+ #161 SMP Tue Jan 21 15:50:02 EET 2020 x86_64 GNU/Linux
>
> # dmidecode
> # dmidecode 3.2
> Scanning /dev/mem for entry point.
> # No SMBIOS nor DMI entry point found, sorry.
>
> # dmidecode --no-sysfs
> # dmidecode 3.2
> Scanning /dev/mem for entry point.
> # No SMBIOS nor DMI entry point found, sorry.
This sounds like at least something of a different issue, with similar
symptoms.
I don't think it is fundamentally wrong to pass the location of the dmi
tables in a command line option. If you can build that command line
option independent of kexec and it takes practically no maintenance then
it does not harm, and can be used as a debug option by others.
My primary concern with your original patch is because it did not
apply to any version of the kernel in Linus's git tree that it had not
been tested on any code.
That said let me lay some background on kexec and efi so we can
have a productive conversation about how to maintain their cooperation
in the long term. I am going to do this from memory so please forgive
me where I get my details slightly off.
EFI has two interesting calls for an operating system.
SetVirtualMap
ExitBootServices
The law of large numbers strongly suggests that when it comes to
emperical testing any interface that is not so heavily used it will fail
to boot all operating systems if it doesn't work will have at least one
broken implementation somewhere. A bug so bad nothing can boot means
the hardware is unshippable and so will not be seen in the wild. As
firmware is essentially fixed once a machine ships this means that all
firmware problems have to be dealt with by the boot loader and the
operating system.
SetVirtualMap by design can be called only once, which is problematic
when you are switching operating systems on a running system (kexec).
Last I was paying attention there were also systems discovered that
won't work if SetVirtualMap is not called at all. I believe the
solution adopted for x86_64 was to always map EFI at the same location
in the page tables and only call SetVirtualMap the first time.
ExitBootSerives is similarly challenging as it can only be called once,
and there are systems that get it wrong if you call it at all. Even if
ExitBootServices works you can't depend on any of the boot services for
the second kernel.
There are two primary uses for kexec. To use the first kernel as a boot
loader in which case it is desiable for everything to work after kexec
is called. To use the second kernel as something to capture a crash
dump in which case simply a best effor is needed and failing cleanly
if something won't work properly.
You are running interactive commands so I presume you are wanting to use
kexec as a bootloader.
I don't know where things are now but for a while was no desire to
address the concerns of people using kexec by the folks implementing EFI
or the folks implementing EFI support in the kernel. But that is
probably how we got into a situation where efi support does not work
cleanly.
EFI choosing to place firwmare tables in somewhere besides their
architecturally defined location does not help.
I don't practically have a system with EFI so I have not personally
cared to fix any of the problems.
My sense is that for making EFI calls from any linux kernel should be
isolated in it's own page table, so isolate as much as possible any
EFI bugs from the rest of the kernel. That is probably also needed to
provide a guard against speculative execution side channel attacks.
I can see doing some work to get EFI functional after kexec if it isn't
but at the same time I am not a fan of performing any unnecessary
firmware calls. Someone sometime will implement one wrong, and it will
be a headache for everyone until it is removed.
By the same token I don't understand the problem with DMI not working.
As I recall all the linux kernel really uses DMI for is to decide which
quirks to apply. It might be better just to pass a board name string
on the kernel command line, and use that string for quirk selection
instead. A simple string seems like an easy to implement and use
debug command line option, that has uses outside of kexec. AKA testing
to see if quirks do what you expect them too.
Which brings us to the question of quirks. Why are quirks important?
If they are that suggests something else is wrong. Maybe that something
else should be fixed.
Why do those boards need the DMI information in the first place?
Eric
On Tue, Jan 21, 2020 at 10:29:35AM -0600, Eric W. Biederman wrote:
> Jean Delvare <[email protected]> writes:
>
> > On Mon, 20 Jan 2020 23:55:43 +0200, Andy Shevchenko wrote:
> >> On Mon, Jan 20, 2020 at 11:44 PM Jean Delvare <[email protected]> wrote:
> >> >
> >> > On Mon, 20 Jan 2020 10:04:04 -0600, Eric W. Biederman wrote:
> >> > > 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.
> >> >
> >> > That must have been long ago. A recent version of dmidecode (>= 3.0)
> >> > running on a recent kernel
> >> > (>= d7f96f97c4031fa4ffdb7801f9aae23e96170a6f, v4.2) will read the DMI
> >> > data from /sys/firmware/dmi/tables, so it is very much relying on the
> >> > kernel doing the right thing. If not, it will still try to fallback to
> >> > reading from /dev/mem directly on certain architectures. You can force
> >> > that old method with --no-sysfs.
> >> >
> >> > Hope that helps,
> >>
> >> I don't understand how it possible can help for in-kernel code, like
> >> DMI quirks in a drivers.
> >
> > OK, just ignore me then, probably I misunderstood the point made by
> > Eric.
>
> No. I just haven't dived into this area of code in a long time.
>
> It seems a little indirect to use dmidecode as the test to see if the
> kernel has the pointer to the dmitables, but with the knowledge you
> provided it seems like a perfectly valid test.
In any case that doesn't work. See my response to Ard.
--
With Best Regards,
Andy Shevchenko
On Mon, Jan 20, 2020 at 02:16:45PM +0200, Andy Shevchenko wrote:
> On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > it has been done for ACPI RSDP.
> >
> > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > particular the default I2C host speed is choosen based on DMI system
> > information and now gets it correct.
>
> Guys, it was quite a long no hear from you.
> Today I found that Microsoft Surface 3 also affected by this.
>
> Can we apply these patches for now until you will find better solution?
>
> P.S. I may resend them rebased on recent vanilla.
Okay, since there is no reply I take it as confirmation that the problem exists
and needs to be addressed. So, I'll send a new version of the series with
updated commit messages (to mention Surface 3 issue).
--
With Best Regards,
Andy Shevchenko
On Thu, May 21, 2020 at 6:55 PM Andy Shevchenko
<[email protected]> wrote:
> On Mon, Jan 20, 2020 at 02:16:45PM +0200, Andy Shevchenko wrote:
> > On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > > it has been done for ACPI RSDP.
> > >
> > > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > > particular the default I2C host speed is choosen based on DMI system
> > > information and now gets it correct.
> >
> > Guys, it was quite a long no hear from you.
> > Today I found that Microsoft Surface 3 also affected by this.
> >
> > Can we apply these patches for now until you will find better solution?
> >
> > P.S. I may resend them rebased on recent vanilla.
>
> Okay, since there is no reply I take it as confirmation that the problem exists
> and needs to be addressed. So, I'll send a new version of the series with
> updated commit messages (to mention Surface 3 issue).
Ah, I found reply from Eric from Jan 21, this year. Somehow it's
slipped thru my eyes.
I'll read it carefully and react accordingly.
--
With Best Regards,
Andy Shevchenko
On Tue, Jan 21, 2020 at 11:17:19AM -0600, Eric W. Biederman wrote:
> Andy Shevchenko <[email protected]> writes:
> > On Tue, Jan 21, 2020 at 12:18:03AM +0100, Ard Biesheuvel wrote:
> >> On Mon, 20 Jan 2020 at 23:31, Andy Shevchenko <[email protected]> wrote:
> >> > On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman <[email protected]> wrote:
> >> > > Andy Shevchenko <[email protected]> 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 <[email protected]>
> >> > 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 0xF0000 and 0x10000. 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
> > -r-------- 1 root root 825 Jan 21 15:41 DMI
> > -r-------- 1 root root 31 Jan 21 15:41 smbios_entry_point
> >
> > # od -Ax -tx1 /sys/firmware/dmi/tables/smbios_entry_point
> > 000000 5f 53 4d 5f 0f 1f 02 08 6a 00 00 00 00 00 00 00
> > 000010 5f 44 4d 49 5f e0 39 03 00 40 5b 7b 0f 00 27
> > 00001f
> >
> > # dmesg | grep -i dmi
> > [ 0.000000] DMI: Microsoft Corporation Surface 3/Surface 3, BIOS 1.50410.78 03/10/2015
> > [ 0.403058] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
> >
> > # dmesg | grep -i smb
> > [ 0.000000] efi: ESRT=0x7b7c6c98 ACPI=0x7ad5a000 ACPI 2.0=0x7ad5a000 SMBIOS=0x7b5f7d18
> > [ 0.000000] SMBIOS 2.8 present.
> >
> > === kexec'ed kernel ===
> > # uname -a
> > (in both cases, see above `uname -a`, the same version)
> > Linux buildroot 5.5.0-rc7+ #161 SMP Tue Jan 21 15:50:02 EET 2020 x86_64 GNU/Linux
> >
> > # dmidecode
> > # dmidecode 3.2
> > Scanning /dev/mem for entry point.
> > # No SMBIOS nor DMI entry point found, sorry.
> >
> > # dmidecode --no-sysfs
> > # dmidecode 3.2
> > Scanning /dev/mem for entry point.
> > # No SMBIOS nor DMI entry point found, sorry.
>
> This sounds like at least something of a different issue, with similar
> symptoms.
>
> I don't think it is fundamentally wrong to pass the location of the dmi
> tables in a command line option. If you can build that command line
> option independent of kexec and it takes practically no maintenance then
> it does not harm, and can be used as a debug option by others.
>
> My primary concern with your original patch is because it did not
> apply to any version of the kernel in Linus's git tree that it had not
> been tested on any code.
As I have told couple of times there is no issue for me to rebase on any
subsytem tree. Do you want EFI one as a base?
> That said let me lay some background on kexec and efi so we can
> have a productive conversation about how to maintain their cooperation
> in the long term. I am going to do this from memory so please forgive
> me where I get my details slightly off.
Thank you for that, but as far as I'm concerned those calls are not significant
in the second kernel for my test purposes. Basically the issue is to supply DMI
information, which is static, to the second kernel.
...
> ExitBootSerives is similarly challenging as it can only be called once,
> and there are systems that get it wrong if you call it at all. Even if
> ExitBootServices works you can't depend on any of the boot services for
> the second kernel.
And I do not need. At least I haven't (yet?) found an issue with that.
...
> There are two primary uses for kexec. To use the first kernel as a boot
> loader in which case it is desiable for everything to work after kexec
> is called. To use the second kernel as something to capture a crash
> dump in which case simply a best effor is needed and failing cleanly
> if something won't work properly.
> You are running interactive commands so I presume you are wanting to use
> kexec as a bootloader.
We are using kexec to run kernel over network. That's how our (local) lab
infrastructure looks like. Basically what we need is to be able to test
drivers on SUT as a primary concern here.
...
> By the same token I don't understand the problem with DMI not working.
> As I recall all the linux kernel really uses DMI for is to decide which
> quirks to apply.
Yes, that's usual (historical) way for quirks on x86.
> It might be better just to pass a board name string
> on the kernel command line, and use that string for quirk selection
> instead. A simple string seems like an easy to implement and use
> debug command line option, that has uses outside of kexec. AKA testing
> to see if quirks do what you expect them too.
Huh?! No way, we have a (1st) kernel platform agnostic. This will make it board
dependent. Moreover, second kernel needs to be *heavily* patched for this.
It's way to nowhere.
> Which brings us to the question of quirks. Why are quirks important?
> If they are that suggests something else is wrong. Maybe that something
> else should be fixed.
> Why do those boards need the DMI information in the first place?
I didn't get a sarcasm in above few paragraphs, but we are living in ideal
world, you know...
So, I will rebase and submit a new version of the series with extended commit
message. Problem is there and should be addressed.
Thanks!
--
With Best Regards,
Andy Shevchenko
+Cc: Ard
On Wed, Jun 02, 2021 at 11:42:14AM +0300, Andy Shevchenko wrote:
> On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > it has been done for ACPI RSDP.
> >
> > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > particular the default I2C host speed is choosen based on DMI system
> > information and now gets it correct.
>
> Still nothing happens for a while and problem still exists.
> Can we do something about it, please?
--
With Best Regards,
Andy Shevchenko
On Tue, Jan 21, 2020 at 12:18:03AM +0100, Ard Biesheuvel wrote:
> On Mon, 20 Jan 2020 at 23:31, Andy Shevchenko <[email protected]> wrote:
> >
> > On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman <[email protected]> wrote:
> > > Andy Shevchenko <[email protected]> writes:
> > > > On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote:
> > > >> 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.
> > > >
> > > > Guys, it was quite a long no hear from you. As I told you the proposed work
> > > > around didn't help. Today I found that Microsoft Surface 3 also affected
> > > > by this.
> > > >
> > > > 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 <[email protected]>
> > 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 0xF0000 and 0x10000. 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?
Can you tell how to do this and I will try to get information?
--
With Best Regards,
Andy Shevchenko
Fixed Ard's address
On Wed, Jun 02, 2021 at 11:37:29AM +0300, Andy Shevchenko wrote:
> On Tue, Jan 21, 2020 at 12:18:03AM +0100, Ard Biesheuvel wrote:
> > On Mon, 20 Jan 2020 at 23:31, Andy Shevchenko <[email protected]> wrote:
> > >
> > > On Mon, Jan 20, 2020 at 9:28 PM Eric W. Biederman <[email protected]> wrote:
> > > > Andy Shevchenko <[email protected]> writes:
> > > > > On Sat, Dec 17, 2016 at 06:57:21PM +0800, Dave Young wrote:
> > > > >> 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.
> > > > >
> > > > > Guys, it was quite a long no hear from you. As I told you the proposed work
> > > > > around didn't help. Today I found that Microsoft Surface 3 also affected
> > > > > by this.
> > > > >
> > > > > 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 <[email protected]>
> > > 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 0xF0000 and 0x10000. 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?
>
> Can you tell how to do this and I will try to get information?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
With Best Regards,
Andy Shevchenko
On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> Until now DMI information is lost when kexec'ing. Fix this in the same way as
> it has been done for ACPI RSDP.
>
> Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> particular the default I2C host speed is choosen based on DMI system
> information and now gets it correct.
Still nothing happens for a while and problem still exists.
Can we do something about it, please?
--
With Best Regards,
Andy Shevchenko
Hi,
On 06/02/21 at 11:53am, Andy Shevchenko wrote:
> +Cc: Ard
>
> On Wed, Jun 02, 2021 at 11:42:14AM +0300, Andy Shevchenko wrote:
> > On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > > it has been done for ACPI RSDP.
> > >
> > > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > > particular the default I2C host speed is choosen based on DMI system
> > > information and now gets it correct.
> >
> > Still nothing happens for a while and problem still exists.
> > Can we do something about it, please?
Seems I totally missed this thread. Old emails lost.
The question Ard asked is to confirm if the firmware converted the
SMBIOS3 addr to a virtual address after exit boot service. I do not
remember some easy way to check it due to lost the context of the code.
But you can try to check it via dmesg|grep SMBIOS both in normal boot
and kexeced boot log. And then compare if those addresses are
identical.
If the SMBIOS3 addr in kexec kernel is different then it should have
been modified by firmware. Then we need patch kernel and kexec-tools to
support it.
You can try below patch to see if it works:
apply a kexec-tools patch to kexec-tools if you do not use kexec -s
(kexec_file_load):
--- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.c
+++ kexec-tools/kexec/arch/i386/x86-linux-setup.c
@@ -533,7 +533,8 @@ struct efi_setup_data {
uint64_t runtime;
uint64_t tables;
uint64_t smbios;
- uint64_t reserved[8];
+ uint64_t smbios3;
+ uint64_t reserved[7];
};
struct setup_data {
@@ -580,6 +581,8 @@ static int get_efi_values(struct efi_set
ret = get_efi_value("/sys/firmware/efi/systab", "SMBIOS=0x",
&esd->smbios);
+ ret |= get_efi_value("/sys/firmware/efi/systab", "SMBIOS3=0x",
+ &esd->smbios3);
ret |= get_efi_value("/sys/firmware/efi/fw_vendor", "0x",
&esd->fw_vendor);
ret |= get_efi_value("/sys/firmware/efi/runtime", "0x",
=============================================
Kernel patch:
--- linux-x86.orig/arch/x86/include/asm/efi.h
+++ linux-x86/arch/x86/include/asm/efi.h
@@ -167,7 +167,8 @@ struct efi_setup_data {
u64 __unused;
u64 tables;
u64 smbios;
- u64 reserved[8];
+ u64 smbios3;
+ u64 reserved[7];
};
extern u64 efi_setup;
--- linux-x86.orig/arch/x86/kernel/kexec-bzimage64.c
+++ linux-x86/arch/x86/kernel/kexec-bzimage64.c
@@ -144,6 +144,7 @@ prepare_add_efi_setup_data(struct boot_p
esd->fw_vendor = efi_fw_vendor;
esd->tables = efi_config_table;
esd->smbios = efi.smbios;
+ esd->smbios3 = efi.smbios3;
sd->type = SETUP_EFI;
sd->len = sizeof(struct efi_setup_data);
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -497,8 +497,8 @@ void __init efi_free_boot_services(void)
* their physical addresses therefore we pass them via setup_data and
* correct those entries to their respective physical addresses here.
*
- * Currently only handles smbios which is necessary for some firmware
- * implementation.
+ * Currently only handles smbios and smbios3 which is necessary for
+ * some firmware implementation.
*/
int __init efi_reuse_config(u64 tables, int nr_tables)
{
@@ -521,7 +521,7 @@ int __init efi_reuse_config(u64 tables,
goto out;
}
- if (!data->smbios)
+ if (!data->smbios && !data->smbios3)
goto out_memremap;
sz = sizeof(efi_config_table_64_t);
@@ -538,8 +538,10 @@ int __init efi_reuse_config(u64 tables,
guid = ((efi_config_table_64_t *)p)->guid;
- if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
+ if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID) && data->smbios)
((efi_config_table_64_t *)p)->table = data->smbios;
+ else if (!efi_guidcmp(guid, SMBIOS3_TABLE_GUID) && data->smbios3)
+ ((efi_config_table_64_t *)p)->table = data->smbios3;
p += sz;
}
early_memunmap(tablep, nr_tables * sz);
Thanks
Dave
On Sat, Jun 05, 2021 at 03:51:05PM +0800, Dave Young wrote:
> Hi,
> On 06/02/21 at 11:53am, Andy Shevchenko wrote:
> > +Cc: Ard
> >
> > On Wed, Jun 02, 2021 at 11:42:14AM +0300, Andy Shevchenko wrote:
> > > On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > > > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > > > it has been done for ACPI RSDP.
> > > >
> > > > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > > > particular the default I2C host speed is choosen based on DMI system
> > > > information and now gets it correct.
> > >
> > > Still nothing happens for a while and problem still exists.
> > > Can we do something about it, please?
>
> Seems I totally missed this thread. Old emails lost.
You can always access to it via lore :-)
https://lore.kernel.org/linux-efi/[email protected]/T/#u
(Okay, it's not full, but contains main parts anyway)
> The question Ard asked is to confirm if the firmware converted the
> SMBIOS3 addr to a virtual address after exit boot service. I do not
> remember some easy way to check it due to lost the context of the code.
> But you can try to check it via dmesg|grep SMBIOS both in normal boot
> and kexeced boot log. And then compare if those addresses are
> identical.
>
> If the SMBIOS3 addr in kexec kernel is different then it should have
> been modified by firmware. Then we need patch kernel and kexec-tools to
> support it.
>
> You can try below patch to see if it works:
So, AFAIU I have to apply patch to kexec tools for the fist kernel + userspace
and apply kernel patch for the second kernel? Or it's all for the first one?
> apply a kexec-tools patch to kexec-tools if you do not use kexec -s
> (kexec_file_load):
Here is how we are using it:
https://github.com/andy-shev/buildroot/blob/intel/board/intel/common/netboot/udhcpc-script.sh#L54
> --- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.c
> +++ kexec-tools/kexec/arch/i386/x86-linux-setup.c
> @@ -533,7 +533,8 @@ struct efi_setup_data {
> uint64_t runtime;
> uint64_t tables;
> uint64_t smbios;
> - uint64_t reserved[8];
> + uint64_t smbios3;
> + uint64_t reserved[7];
> };
>
> struct setup_data {
> @@ -580,6 +581,8 @@ static int get_efi_values(struct efi_set
>
> ret = get_efi_value("/sys/firmware/efi/systab", "SMBIOS=0x",
> &esd->smbios);
> + ret |= get_efi_value("/sys/firmware/efi/systab", "SMBIOS3=0x",
> + &esd->smbios3);
> ret |= get_efi_value("/sys/firmware/efi/fw_vendor", "0x",
> &esd->fw_vendor);
> ret |= get_efi_value("/sys/firmware/efi/runtime", "0x",
>
> =============================================
> Kernel patch:
>
> --- linux-x86.orig/arch/x86/include/asm/efi.h
> +++ linux-x86/arch/x86/include/asm/efi.h
> @@ -167,7 +167,8 @@ struct efi_setup_data {
> u64 __unused;
> u64 tables;
> u64 smbios;
> - u64 reserved[8];
> + u64 smbios3;
> + u64 reserved[7];
> };
>
> extern u64 efi_setup;
> --- linux-x86.orig/arch/x86/kernel/kexec-bzimage64.c
> +++ linux-x86/arch/x86/kernel/kexec-bzimage64.c
> @@ -144,6 +144,7 @@ prepare_add_efi_setup_data(struct boot_p
> esd->fw_vendor = efi_fw_vendor;
> esd->tables = efi_config_table;
> esd->smbios = efi.smbios;
> + esd->smbios3 = efi.smbios3;
>
> sd->type = SETUP_EFI;
> sd->len = sizeof(struct efi_setup_data);
> --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> +++ linux-x86/arch/x86/platform/efi/quirks.c
> @@ -497,8 +497,8 @@ void __init efi_free_boot_services(void)
> * their physical addresses therefore we pass them via setup_data and
> * correct those entries to their respective physical addresses here.
> *
> - * Currently only handles smbios which is necessary for some firmware
> - * implementation.
> + * Currently only handles smbios and smbios3 which is necessary for
> + * some firmware implementation.
> */
> int __init efi_reuse_config(u64 tables, int nr_tables)
> {
> @@ -521,7 +521,7 @@ int __init efi_reuse_config(u64 tables,
> goto out;
> }
>
> - if (!data->smbios)
> + if (!data->smbios && !data->smbios3)
> goto out_memremap;
>
> sz = sizeof(efi_config_table_64_t);
> @@ -538,8 +538,10 @@ int __init efi_reuse_config(u64 tables,
>
> guid = ((efi_config_table_64_t *)p)->guid;
>
> - if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID))
> + if (!efi_guidcmp(guid, SMBIOS_TABLE_GUID) && data->smbios)
> ((efi_config_table_64_t *)p)->table = data->smbios;
> + else if (!efi_guidcmp(guid, SMBIOS3_TABLE_GUID) && data->smbios3)
> + ((efi_config_table_64_t *)p)->table = data->smbios3;
> p += sz;
> }
> early_memunmap(tablep, nr_tables * sz);
>
>
> Thanks
> Dave
>
--
With Best Regards,
Andy Shevchenko
On Mon, Jun 07, 2021 at 07:22:21PM +0300, Andy Shevchenko wrote:
> On Sat, Jun 05, 2021 at 03:51:05PM +0800, Dave Young wrote:
> > On 06/02/21 at 11:53am, Andy Shevchenko wrote:
> > > On Wed, Jun 02, 2021 at 11:42:14AM +0300, Andy Shevchenko wrote:
> > > > On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > > > > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > > > > it has been done for ACPI RSDP.
> > > > >
> > > > > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > > > > particular the default I2C host speed is choosen based on DMI system
> > > > > information and now gets it correct.
> > > >
> > > > Still nothing happens for a while and problem still exists.
> > > > Can we do something about it, please?
> >
> > Seems I totally missed this thread. Old emails lost.
>
> You can always access to it via lore :-)
> https://lore.kernel.org/linux-efi/[email protected]/T/#u
>
> (Okay, it's not full, but contains main parts anyway)
>
>
> > The question Ard asked is to confirm if the firmware converted the
> > SMBIOS3 addr to a virtual address after exit boot service. I do not
> > remember some easy way to check it due to lost the context of the code.
> > But you can try to check it via dmesg|grep SMBIOS both in normal boot
> > and kexeced boot log. And then compare if those addresses are
> > identical.
> >
> > If the SMBIOS3 addr in kexec kernel is different then it should have
> > been modified by firmware. Then we need patch kernel and kexec-tools to
> > support it.
> >
> > You can try below patch to see if it works:
>
> So, AFAIU I have to apply patch to kexec tools for the fist kernel + userspace
> and apply kernel patch for the second kernel? Or it's all for the first one?
>
> > apply a kexec-tools patch to kexec-tools if you do not use kexec -s
> > (kexec_file_load):
>
> Here is how we are using it:
> https://github.com/andy-shev/buildroot/blob/intel/board/intel/common/netboot/udhcpc-script.sh#L54
Okay, thanks for the patches. I have applied them to both kernels, so the first
one and second one are the same and kexec tools have a patch provided in the
user space of the both kernels (only first one in use though).
Before applying your patch, I have reverted my hacks (as per this series).
Result is:
# uname -a
Linux buildroot 5.13.0-rc5+ #1 SMP Mon Jun 7 19:49:40 EEST 2021 i586 GNU/Linux
# dmidecode
# dmidecode 3.3
Scanning /dev/mem for entry point.
# No SMBIOS nor DMI entry point found, sorry.
I.o.w. it does NOT fix the issue. My patches do (with a hint from user space).
--
With Best Regards,
Andy Shevchenko
On 06/07/21 at 08:18pm, Andy Shevchenko wrote:
> On Mon, Jun 07, 2021 at 07:22:21PM +0300, Andy Shevchenko wrote:
> > On Sat, Jun 05, 2021 at 03:51:05PM +0800, Dave Young wrote:
> > > On 06/02/21 at 11:53am, Andy Shevchenko wrote:
> > > > On Wed, Jun 02, 2021 at 11:42:14AM +0300, Andy Shevchenko wrote:
> > > > > On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > > > > > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > > > > > it has been done for ACPI RSDP.
> > > > > >
> > > > > > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > > > > > particular the default I2C host speed is choosen based on DMI system
> > > > > > information and now gets it correct.
> > > > >
> > > > > Still nothing happens for a while and problem still exists.
> > > > > Can we do something about it, please?
> > >
> > > Seems I totally missed this thread. Old emails lost.
> >
> > You can always access to it via lore :-)
> > https://lore.kernel.org/linux-efi/[email protected]/T/#u
Thanks. Hmm, this is for 32bit efi. kexec efi boot support was only
added for 64bit. So if 32bit dmidecode does not work I'm not surprise.
> >
> > (Okay, it's not full, but contains main parts anyway)
> >
> >
> > > The question Ard asked is to confirm if the firmware converted the
> > > SMBIOS3 addr to a virtual address after exit boot service. I do not
> > > remember some easy way to check it due to lost the context of the code.
> > > But you can try to check it via dmesg|grep SMBIOS both in normal boot
> > > and kexeced boot log. And then compare if those addresses are
> > > identical.
> > >
> > > If the SMBIOS3 addr in kexec kernel is different then it should have
> > > been modified by firmware. Then we need patch kernel and kexec-tools to
> > > support it.
> > >
> > > You can try below patch to see if it works:
> >
> > So, AFAIU I have to apply patch to kexec tools for the fist kernel + userspace
> > and apply kernel patch for the second kernel? Or it's all for the first one?
> >
> > > apply a kexec-tools patch to kexec-tools if you do not use kexec -s
> > > (kexec_file_load):
> >
> > Here is how we are using it:
> > https://github.com/andy-shev/buildroot/blob/intel/board/intel/common/netboot/udhcpc-script.sh#L54
>
> Okay, thanks for the patches. I have applied them to both kernels, so the first
> one and second one are the same and kexec tools have a patch provided in the
> user space of the both kernels (only first one in use though).
>
> Before applying your patch, I have reverted my hacks (as per this series).
>
> Result is:
>
> # uname -a
> Linux buildroot 5.13.0-rc5+ #1 SMP Mon Jun 7 19:49:40 EEST 2021 i586 GNU/Linux
> # dmidecode
> # dmidecode 3.3
> Scanning /dev/mem for entry point.
> # No SMBIOS nor DMI entry point found, sorry.
>
> I.o.w. it does NOT fix the issue. My patches do (with a hint from user space).
As I said, since it is 32bit efi, so your test results are expected,
also no need to check the kernel log about SMBIOS3 address changed or
not.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Thanks
Dave
On Tue, Jun 8, 2021 at 3:29 PM Dave Young <[email protected]> wrote:
> On 06/07/21 at 08:18pm, Andy Shevchenko wrote:
> > On Mon, Jun 07, 2021 at 07:22:21PM +0300, Andy Shevchenko wrote:
> > > On Sat, Jun 05, 2021 at 03:51:05PM +0800, Dave Young wrote:
> > > > On 06/02/21 at 11:53am, Andy Shevchenko wrote:
> > > > > On Wed, Jun 02, 2021 at 11:42:14AM +0300, Andy Shevchenko wrote:
> > > > > > On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > > > > > > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > > > > > > it has been done for ACPI RSDP.
> > > > > > >
> > > > > > > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > > > > > > particular the default I2C host speed is choosen based on DMI system
> > > > > > > information and now gets it correct.
> > > > > >
> > > > > > Still nothing happens for a while and problem still exists.
> > > > > > Can we do something about it, please?
> > > >
> > > > Seems I totally missed this thread. Old emails lost.
> > >
> > > You can always access to it via lore :-)
> > > https://lore.kernel.org/linux-efi/[email protected]/T/#u
>
> Thanks. Hmm, this is for 32bit efi. kexec efi boot support was only
> added for 64bit. So if 32bit dmidecode does not work I'm not surprise.
>
> > >
> > > (Okay, it's not full, but contains main parts anyway)
> > >
> > >
> > > > The question Ard asked is to confirm if the firmware converted the
> > > > SMBIOS3 addr to a virtual address after exit boot service. I do not
> > > > remember some easy way to check it due to lost the context of the code.
> > > > But you can try to check it via dmesg|grep SMBIOS both in normal boot
> > > > and kexeced boot log. And then compare if those addresses are
> > > > identical.
> > > >
> > > > If the SMBIOS3 addr in kexec kernel is different then it should have
> > > > been modified by firmware. Then we need patch kernel and kexec-tools to
> > > > support it.
> > > >
> > > > You can try below patch to see if it works:
> > >
> > > So, AFAIU I have to apply patch to kexec tools for the fist kernel + userspace
> > > and apply kernel patch for the second kernel? Or it's all for the first one?
> > >
> > > > apply a kexec-tools patch to kexec-tools if you do not use kexec -s
> > > > (kexec_file_load):
> > >
> > > Here is how we are using it:
> > > https://github.com/andy-shev/buildroot/blob/intel/board/intel/common/netboot/udhcpc-script.sh#L54
> >
> > Okay, thanks for the patches. I have applied them to both kernels, so the first
> > one and second one are the same and kexec tools have a patch provided in the
> > user space of the both kernels (only first one in use though).
> >
> > Before applying your patch, I have reverted my hacks (as per this series).
> >
> > Result is:
> >
> > # uname -a
> > Linux buildroot 5.13.0-rc5+ #1 SMP Mon Jun 7 19:49:40 EEST 2021 i586 GNU/Linux
> > # dmidecode
> > # dmidecode 3.3
> > Scanning /dev/mem for entry point.
> > # No SMBIOS nor DMI entry point found, sorry.
> >
> > I.o.w. it does NOT fix the issue. My patches do (with a hint from user space).
>
> As I said, since it is 32bit efi, so your test results are expected,
> also no need to check the kernel log about SMBIOS3 address changed or
> not.
So, what shall I do? It's already 5 years passed without any progress
while my patches definitely help here.
Should I rebase and resubmit?
--
With Best Regards,
Andy Shevchenko
On 06/08/21 at 03:38pm, Andy Shevchenko wrote:
> On Tue, Jun 8, 2021 at 3:29 PM Dave Young <[email protected]> wrote:
> > On 06/07/21 at 08:18pm, Andy Shevchenko wrote:
> > > On Mon, Jun 07, 2021 at 07:22:21PM +0300, Andy Shevchenko wrote:
> > > > On Sat, Jun 05, 2021 at 03:51:05PM +0800, Dave Young wrote:
> > > > > On 06/02/21 at 11:53am, Andy Shevchenko wrote:
> > > > > > On Wed, Jun 02, 2021 at 11:42:14AM +0300, Andy Shevchenko wrote:
> > > > > > > On Fri, Dec 02, 2016 at 09:54:14PM +0200, Andy Shevchenko wrote:
> > > > > > > > Until now DMI information is lost when kexec'ing. Fix this in the same way as
> > > > > > > > it has been done for ACPI RSDP.
> > > > > > > >
> > > > > > > > Series has been tested on Galileo Gen2 where DMI is used by drivers, in
> > > > > > > > particular the default I2C host speed is choosen based on DMI system
> > > > > > > > information and now gets it correct.
> > > > > > >
> > > > > > > Still nothing happens for a while and problem still exists.
> > > > > > > Can we do something about it, please?
> > > > >
> > > > > Seems I totally missed this thread. Old emails lost.
> > > >
> > > > You can always access to it via lore :-)
> > > > https://lore.kernel.org/linux-efi/[email protected]/T/#u
> >
> > Thanks. Hmm, this is for 32bit efi. kexec efi boot support was only
> > added for 64bit. So if 32bit dmidecode does not work I'm not surprise.
> >
> > > >
> > > > (Okay, it's not full, but contains main parts anyway)
> > > >
> > > >
> > > > > The question Ard asked is to confirm if the firmware converted the
> > > > > SMBIOS3 addr to a virtual address after exit boot service. I do not
> > > > > remember some easy way to check it due to lost the context of the code.
> > > > > But you can try to check it via dmesg|grep SMBIOS both in normal boot
> > > > > and kexeced boot log. And then compare if those addresses are
> > > > > identical.
> > > > >
> > > > > If the SMBIOS3 addr in kexec kernel is different then it should have
> > > > > been modified by firmware. Then we need patch kernel and kexec-tools to
> > > > > support it.
> > > > >
> > > > > You can try below patch to see if it works:
> > > >
> > > > So, AFAIU I have to apply patch to kexec tools for the fist kernel + userspace
> > > > and apply kernel patch for the second kernel? Or it's all for the first one?
> > > >
> > > > > apply a kexec-tools patch to kexec-tools if you do not use kexec -s
> > > > > (kexec_file_load):
> > > >
> > > > Here is how we are using it:
> > > > https://github.com/andy-shev/buildroot/blob/intel/board/intel/common/netboot/udhcpc-script.sh#L54
> > >
> > > Okay, thanks for the patches. I have applied them to both kernels, so the first
> > > one and second one are the same and kexec tools have a patch provided in the
> > > user space of the both kernels (only first one in use though).
> > >
> > > Before applying your patch, I have reverted my hacks (as per this series).
> > >
> > > Result is:
> > >
> > > # uname -a
> > > Linux buildroot 5.13.0-rc5+ #1 SMP Mon Jun 7 19:49:40 EEST 2021 i586 GNU/Linux
> > > # dmidecode
> > > # dmidecode 3.3
> > > Scanning /dev/mem for entry point.
> > > # No SMBIOS nor DMI entry point found, sorry.
> > >
> > > I.o.w. it does NOT fix the issue. My patches do (with a hint from user space).
> >
> > As I said, since it is 32bit efi, so your test results are expected,
> > also no need to check the kernel log about SMBIOS3 address changed or
> > not.
>
> So, what shall I do? It's already 5 years passed without any progress
> while my patches definitely help here.
> Should I rebase and resubmit?
Probably it is doable to have kexec on 32bit efi working
without runtime service support, that means no need the trick of fixed
mapping.
If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
patches for test.
>
> --
> With Best Regards,
> Andy Shevchenko
>
Thanks
Dave
> Probably it is doable to have kexec on 32bit efi working
> without runtime service support, that means no need the trick of fixed
> mapping.
>
> If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
> patches for test.
Unfortunately I failed to setup a 32bit efi guest, here are some
untested draft patches, please have a try.
========= kernel draft patch ==============
---
arch/x86/boot/header.S | 2 +-
arch/x86/platform/efi/efi.c | 6 +++---
arch/x86/platform/efi/quirks.c | 3 ---
3 files changed, 4 insertions(+), 7 deletions(-)
--- linux-x86.orig/arch/x86/boot/header.S
+++ linux-x86/arch/x86/boot/header.S
@@ -416,7 +416,7 @@ xloadflags:
# define XLF23 0
#endif
-#if defined(CONFIG_X86_64) && defined(CONFIG_EFI) && defined(CONFIG_KEXEC_CORE)
+#if defined(CONFIG_EFI) && defined(CONFIG_KEXEC_CORE)
# define XLF4 XLF_EFI_KEXEC
#else
# define XLF4 0
--- linux-x86.orig/arch/x86/platform/efi/efi.c
+++ linux-x86/arch/x86/platform/efi/efi.c
@@ -710,10 +710,10 @@ static void __init kexec_enter_virtual_m
unsigned int num_pages;
/*
- * We don't do virtual mode, since we don't do runtime services, on
- * non-native EFI.
+ * We don't do virtual mode, since we don't do runtime services
+ * on non-native or IA32 EFI.
*/
- if (efi_is_mixed()) {
+ if (!efi_enabled(EFI_64BIT)) {
efi_memmap_unmap();
clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
return;
--- linux-x86.orig/arch/x86/platform/efi/quirks.c
+++ linux-x86/arch/x86/platform/efi/quirks.c
@@ -524,9 +524,6 @@ int __init efi_reuse_config(u64 tables,
if (!efi_setup)
return 0;
- if (!efi_enabled(EFI_64BIT))
- return 0;
-
data = early_memremap(efi_setup, sizeof(*data));
if (!data) {
ret = -ENOMEM;
========= kexec-tools draft patch =========
---
kexec/arch/i386/kexec-bzImage.c | 5 +++++
1 file changed, 5 insertions(+)
--- kexec-tools.orig/kexec/arch/i386/kexec-bzImage.c
+++ kexec-tools/kexec/arch/i386/kexec-bzImage.c
@@ -83,6 +83,11 @@ int bzImage_probe(const char *buf, off_t
if (probe_debug) {
fprintf(stderr, "It's a bzImage\n");
}
+
+#define XLF_EFI_KEXEC (1 << 4)
+ if ((header->xloadflags & XLF_EFI_KEXEC) == XLF_EFI_KEXEC)
+ bzImage_support_efi_boot = 1;
+
return 0;
}
On Sat, Jun 12, 2021 at 12:40:57PM +0800, Dave Young wrote:
> > Probably it is doable to have kexec on 32bit efi working
> > without runtime service support, that means no need the trick of fixed
> > mapping.
> >
> > If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
> > patches for test.
>
> Unfortunately I failed to setup a 32bit efi guest, here are some
> untested draft patches, please have a try.
Thanks for the patches.
As previously, I have reverted my hacks and applied your patches (also I
dropped patches from previous mail against kernel and kexec-tools) for both
kernel and user space on first and second environments.
It does NOT solve the issue.
If there is no idea pops up soon, I'm going to resend my series that
workarounds the issue.
--
With Best Regards,
Andy Shevchenko
On Mon, Jun 14, 2021 at 06:38:30PM +0300, Andy Shevchenko wrote:
> On Sat, Jun 12, 2021 at 12:40:57PM +0800, Dave Young wrote:
> > > Probably it is doable to have kexec on 32bit efi working
> > > without runtime service support, that means no need the trick of fixed
> > > mapping.
> > >
> > > If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
> > > patches for test.
> >
> > Unfortunately I failed to setup a 32bit efi guest, here are some
> > untested draft patches, please have a try.
>
> Thanks for the patches.
>
> As previously, I have reverted my hacks and applied your patches (also I
> dropped patches from previous mail against kernel and kexec-tools) for both
> kernel and user space on first and second environments.
>
> It does NOT solve the issue.
>
> If there is no idea pops up soon, I'm going to resend my series that
> workarounds the issue.
Hold on, I may have made a mistake during testing. Let me retest this.
--
With Best Regards,
Andy Shevchenko
On Mon, Jun 14, 2021 at 08:07:33PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 14, 2021 at 06:38:30PM +0300, Andy Shevchenko wrote:
> > On Sat, Jun 12, 2021 at 12:40:57PM +0800, Dave Young wrote:
> > > > Probably it is doable to have kexec on 32bit efi working
> > > > without runtime service support, that means no need the trick of fixed
> > > > mapping.
> > > >
> > > > If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
> > > > patches for test.
> > >
> > > Unfortunately I failed to setup a 32bit efi guest, here are some
> > > untested draft patches, please have a try.
> >
> > Thanks for the patches.
> >
> > As previously, I have reverted my hacks and applied your patches (also I
> > dropped patches from previous mail against kernel and kexec-tools) for both
> > kernel and user space on first and second environments.
> >
> > It does NOT solve the issue.
> >
> > If there is no idea pops up soon, I'm going to resend my series that
> > workarounds the issue.
>
> Hold on, I may have made a mistake during testing. Let me retest this.
Double checked, confirmed that it's NOT working.
--
With Best Regards,
Andy Shevchenko
On Mon, 14 Jun 2021 at 19:27, Andy Shevchenko <[email protected]> wrote:
>
> On Mon, Jun 14, 2021 at 08:07:33PM +0300, Andy Shevchenko wrote:
> > On Mon, Jun 14, 2021 at 06:38:30PM +0300, Andy Shevchenko wrote:
> > > On Sat, Jun 12, 2021 at 12:40:57PM +0800, Dave Young wrote:
> > > > > Probably it is doable to have kexec on 32bit efi working
> > > > > without runtime service support, that means no need the trick of fixed
> > > > > mapping.
> > > > >
> > > > > If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
> > > > > patches for test.
> > > >
> > > > Unfortunately I failed to setup a 32bit efi guest, here are some
> > > > untested draft patches, please have a try.
> > >
> > > Thanks for the patches.
> > >
> > > As previously, I have reverted my hacks and applied your patches (also I
> > > dropped patches from previous mail against kernel and kexec-tools) for both
> > > kernel and user space on first and second environments.
> > >
> > > It does NOT solve the issue.
> > >
> > > If there is no idea pops up soon, I'm going to resend my series that
> > > workarounds the issue.
> >
> > Hold on, I may have made a mistake during testing. Let me retest this.
>
> Double checked, confirmed that it's NOT working.
>
Apologies for chiming in so late - in my defence, I was on vacation :-)
So if I understand the thread correctly, the Surface 3 provides a
SMBIOS entry point (not SMBIOS3), and it does not get picked up by the
second kernel, right?
I would still prefer to get to the bottom of this before papering over
it with command line options. If the memory gets corrupted by the
first kernel, maybe we are not preserving it correctly in the first
kernel.
On Mon, Jul 19, 2021 at 10:53 AM Ard Biesheuvel <[email protected]> wrote:
> On Mon, 14 Jun 2021 at 19:27, Andy Shevchenko <[email protected]> wrote:
> > On Mon, Jun 14, 2021 at 08:07:33PM +0300, Andy Shevchenko wrote:
> > > On Mon, Jun 14, 2021 at 06:38:30PM +0300, Andy Shevchenko wrote:
> > > > On Sat, Jun 12, 2021 at 12:40:57PM +0800, Dave Young wrote:
> > > > > > Probably it is doable to have kexec on 32bit efi working
> > > > > > without runtime service support, that means no need the trick of fixed
> > > > > > mapping.
> > > > > >
> > > > > > If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
> > > > > > patches for test.
> > > > >
> > > > > Unfortunately I failed to setup a 32bit efi guest, here are some
> > > > > untested draft patches, please have a try.
> > > >
> > > > Thanks for the patches.
> > > >
> > > > As previously, I have reverted my hacks and applied your patches (also I
> > > > dropped patches from previous mail against kernel and kexec-tools) for both
> > > > kernel and user space on first and second environments.
> > > >
> > > > It does NOT solve the issue.
> > > >
> > > > If there is no idea pops up soon, I'm going to resend my series that
> > > > workarounds the issue.
> > >
> > > Hold on, I may have made a mistake during testing. Let me retest this.
> >
> > Double checked, confirmed that it's NOT working.
>
> Apologies for chiming in so late - in my defence, I was on vacation :-)
>
> So if I understand the thread correctly, the Surface 3 provides a
> SMBIOS entry point (not SMBIOS3), and it does not get picked up by the
> second kernel, right?
>
> I would still prefer to get to the bottom of this before papering over
> it with command line options. If the memory gets corrupted by the
> first kernel, maybe we are not preserving it correctly in the first
> kernel.
There are _at least_ two platforms which are affected by this:
- Intel Galileo
- Microsoft Surface 3
For the time being I'm testing this on the former one. If we get
something working there, I will perform similar tests on the latter
one. And who knows how many more platforms are affected, because kexec
is usually not what many people are using every day, however we (my
teammates and I) use such a setup _a lot_.on a number of platforms It
appears that only those two were found in our zoo to behave badly.
--
With Best Regards,
Andy Shevchenko
On Mon, Jun 14, 2021 at 08:27:36PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 14, 2021 at 08:07:33PM +0300, Andy Shevchenko wrote:
> > On Mon, Jun 14, 2021 at 06:38:30PM +0300, Andy Shevchenko wrote:
> > > On Sat, Jun 12, 2021 at 12:40:57PM +0800, Dave Young wrote:
> > > > > Probably it is doable to have kexec on 32bit efi working
> > > > > without runtime service support, that means no need the trick of fixed
> > > > > mapping.
> > > > >
> > > > > If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
> > > > > patches for test.
> > > >
> > > > Unfortunately I failed to setup a 32bit efi guest, here are some
> > > > untested draft patches, please have a try.
> > >
> > > Thanks for the patches.
> > >
> > > As previously, I have reverted my hacks and applied your patches (also I
> > > dropped patches from previous mail against kernel and kexec-tools) for both
> > > kernel and user space on first and second environments.
> > >
> > > It does NOT solve the issue.
> > >
> > > If there is no idea pops up soon, I'm going to resend my series that
> > > workarounds the issue.
> >
> > Hold on, I may have made a mistake during testing. Let me retest this.
>
> Double checked, confirmed that it's NOT working.
Any news here?
Shall I resend my series?
--
With Best Regards,
Andy Shevchenko
On Wed, 6 Oct 2021 at 18:28, Andy Shevchenko <[email protected]> wrote:
>
> On Mon, Jun 14, 2021 at 08:27:36PM +0300, Andy Shevchenko wrote:
> > On Mon, Jun 14, 2021 at 08:07:33PM +0300, Andy Shevchenko wrote:
> > > On Mon, Jun 14, 2021 at 06:38:30PM +0300, Andy Shevchenko wrote:
> > > > On Sat, Jun 12, 2021 at 12:40:57PM +0800, Dave Young wrote:
> > > > > > Probably it is doable to have kexec on 32bit efi working
> > > > > > without runtime service support, that means no need the trick of fixed
> > > > > > mapping.
> > > > > >
> > > > > > If I can restore my vm to boot 32bit efi on this weekend then I may provide some draft
> > > > > > patches for test.
> > > > >
> > > > > Unfortunately I failed to setup a 32bit efi guest, here are some
> > > > > untested draft patches, please have a try.
> > > >
> > > > Thanks for the patches.
> > > >
> > > > As previously, I have reverted my hacks and applied your patches (also I
> > > > dropped patches from previous mail against kernel and kexec-tools) for both
> > > > kernel and user space on first and second environments.
> > > >
> > > > It does NOT solve the issue.
> > > >
> > > > If there is no idea pops up soon, I'm going to resend my series that
> > > > workarounds the issue.
> > >
> > > Hold on, I may have made a mistake during testing. Let me retest this.
> >
> > Double checked, confirmed that it's NOT working.
>
> Any news here?
>
> Shall I resend my series?
>
As I said before:
"""
I would still prefer to get to the bottom of this before papering over
it with command line options. If the memory gets corrupted by the
first kernel, maybe we are not preserving it correctly in the first
kernel.
"""
On Thu, Oct 7, 2021 at 10:20 AM Ard Biesheuvel <[email protected]> wrote:
> On Wed, 6 Oct 2021 at 18:28, Andy Shevchenko <[email protected]> wrote:
> > On Mon, Jun 14, 2021 at 08:27:36PM +0300, Andy Shevchenko wrote:
> > > On Mon, Jun 14, 2021 at 08:07:33PM +0300, Andy Shevchenko wrote:
...
> > > Double checked, confirmed that it's NOT working.
> >
> > Any news here?
> >
> > Shall I resend my series?
>
> As I said before:
>
> """
> I would still prefer to get to the bottom of this before papering over
> it with command line options. If the memory gets corrupted by the
> first kernel, maybe we are not preserving it correctly in the first
> kernel.
> """
And I can't agree more, but above I asked about news, implying if
there is anything to test?
The issue is still there and it becomes a bit annoying to see my hack
patches in every tree I have been using.
--
With Best Regards,
Andy Shevchenko
On Thu, 7 Oct 2021 at 09:23, Andy Shevchenko <[email protected]> wrote:
>
> On Thu, Oct 7, 2021 at 10:20 AM Ard Biesheuvel <[email protected]> wrote:
> > On Wed, 6 Oct 2021 at 18:28, Andy Shevchenko <[email protected]> wrote:
> > > On Mon, Jun 14, 2021 at 08:27:36PM +0300, Andy Shevchenko wrote:
> > > > On Mon, Jun 14, 2021 at 08:07:33PM +0300, Andy Shevchenko wrote:
>
> ...
>
> > > > Double checked, confirmed that it's NOT working.
> > >
> > > Any news here?
> > >
> > > Shall I resend my series?
> >
> > As I said before:
> >
> > """
> > I would still prefer to get to the bottom of this before papering over
> > it with command line options. If the memory gets corrupted by the
> > first kernel, maybe we are not preserving it correctly in the first
> > kernel.
> > """
>
> And I can't agree more, but above I asked about news, implying if
> there is anything to test?
> The issue is still there and it becomes a bit annoying to see my hack
> patches in every tree I have been using.
>
If nobody can be bothered to properly diagnose this, how important is
it, really?