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

[Jean Delvare]

Hi Andy,

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.

---
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

[Dave Young]

Post by Jean Delvare
Hi Andy,

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?

Post by Jean Delvare
Adding Eric to Cc for his opinion.

---
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
http://lists.infradead.org/mailman/listinfo/kexec

[Andy Shevchenko]

Post by Dave Young

Post by Jean Delvare
Hi Andy,

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.

[Jean Delvare]

Post by Andy Shevchenko

Post by Dave Young

Post by Jean Delvare
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?

[Dave Young]

Ccing efi people.

Post by Jean Delvare

Post by Andy Shevchenko

Post by Dave Young

Post by Jean Delvare
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

Post by Jean Delvare
--
Jean Delvare
SUSE L3 Support

[Dave Young]

Post by Andy Shevchenko

Post by Dave Young

Post by Jean Delvare
Hi Andy,

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.

Post by Andy Shevchenko
--
Intel Finland Oy