[PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[Yi Li]

SMBIOS is important for server hardware vendors. It implements a spec for
providing descriptive information about the platform. Things like serial
numbers, physical layout of the ports, build configuration data, and the like.

This has been tested by dmidecode and lshw tools.

Signed-off-by: Yi Li <yi.li@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---

As Ard's suggestion, tested the patch on the kernel with/without EFI
support to boot. The bootlog and dmidecode/lshw works fine.
I will send the log with another email.

 arch/arm64/Kconfig           |   11 +++++++++++
 arch/arm64/include/asm/dmi.h |   31 +++++++++++++++++++++++++++++++
 arch/arm64/kernel/efi.c      |   14 ++++++++++++++
 3 files changed, 56 insertions(+)
 create mode 100644 arch/arm64/include/asm/dmi.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..c69ab5a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -368,6 +368,17 @@ config EFI
 	  allow the kernel to be booted as an EFI application. This
 	  is only useful on systems that have UEFI firmware.
 
+config DMI
+	bool "Enable support for SMBIOS (DMI) tables"
+	depends on EFI
+	default y
+	help
+	  This enables SMBIOS/DMI feature for systems.
+
+	  This option is only useful on systems that have UEFI firmware.
+	  However, even with this option, the resultant kernel should
+	  continue to boot on existing non-UEFI platforms.
+
 endmenu
 
 menu "Userspace binary formats"
diff --git a/arch/arm64/include/asm/dmi.h b/arch/arm64/include/asm/dmi.h
new file mode 100644
index 0000000..69d37d8
--- /dev/null
+++ b/arch/arm64/include/asm/dmi.h
@@ -0,0 +1,31 @@
+/*
+ * arch/arm64/include/asm/dmi.h
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Written by: Yi Li (yi.li at linaro.org)
+ *
+ * based on arch/ia64/include/asm/dmi.h
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#ifndef __ASM_DMI_H
+#define __ASM_DMI_H
+
+#include <linux/io.h>
+#include <linux/slab.h>
+
+/*
+ * According to section 2.3.6 of the UEFI spec, the firmware should not
+ * request a virtual mapping for configuration tables such as SMBIOS.
+ * This means we have to map them before use.
+ */
+#define dmi_early_remap(x, l)		ioremap_cache(x, l)
+#define dmi_early_unmap(x, l)		iounmap(x)
+#define dmi_remap(x, l)			ioremap_cache(x, l)
+#define dmi_unmap(x)			iounmap(x)
+#define dmi_alloc(l)			kzalloc(l, GFP_KERNEL)
+
+#endif
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 03aaa99..f00617f 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -11,6 +11,7 @@
  *
  */
 
+#include <linux/dmi.h>
 #include <linux/efi.h>
 #include <linux/export.h>
 #include <linux/memblock.h>
@@ -479,3 +480,16 @@ err_unmap:
 	return -1;
 }
 early_initcall(arm64_enter_virtual_mode);
+
+static int __init arm64_core_init(void)
+{
+/*
+ * DMI depends on EFI on arm64, and dmi_scan_machine() needs to be
+ * called early because dmi_id_init(), which is an arch_initcall itself,
+ * depends on dmi_scan_machine() having been called already.
+ */
+
+	dmi_scan_machine();
+	return 0;
+}
+core_initcall(arm64_core_init);
-- 
1.7.9.5

[PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[Catalin Marinas]

On Sat, Oct 04, 2014 at 04:46:43PM +0100, Yi Li wrote:
> SMBIOS is important for server hardware vendors. It implements a spec for
> providing descriptive information about the platform. Things like serial
> numbers, physical layout of the ports, build configuration data, and the like.
> 
> This has been tested by dmidecode and lshw tools.
> 
> Signed-off-by: Yi Li <yi.li@linaro.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> 
> As Ard's suggestion, tested the patch on the kernel with/without EFI
> support to boot. The bootlog and dmidecode/lshw works fine.
> I will send the log with another email.

Thanks but it's late for 3.18. We'll probably queue it later for 3.19
(hopefully it's ok this time ;)).

-- 
Catalin

[PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[Jon Masters]

Hi Yi Li,

I would like some advice on the below patch. First, a little background.

I /may/ need to use SMBIOS provided data on ARMv8 systems to enumerate
the number of physical underlying CPU sockets present. This is provided
in one Type4 DMI structure per physical socket. Using that fact (such
data is already provided by all of the reference ARMv8 server systems),
and a variable interpretation of the CPU affinity data, we can refactor
the topology.c code to understand threads vs cores vs sockets without
getting confused by the extra levels of hierarchy for clusters.

I am going back over some older patches, including this one to
understand the DMI port, and I notice that you call dmi_scan_machine
from an early_initcall. This will run from the init thread, after we've
done basic SMP setup in smp_prepare_cpus, which is where we stash
cpu_topology data, which is after I already need DMI data available.

So. If I wanted this available prior to early_initcall time, would it be
reasonable to follow e.g. x86 and move this early in the boot? I'm not
necessarily going to ask to upstream such a change (since I expect to be
able to solve the underlying problem I am looking to address in a
different fashion soon), but first want to know if it would be
reasonable to ask to do that anyway.

Jon.

P.S. I'm not interested at all in replies pointing me to the existing DT
cpu topology binding, which I am well aware of, but it does also not
actually solve the problem I have :)

On 10/04/2014 11:46 AM, Yi Li wrote:

<snip>

> +
> +static int __init arm64_core_init(void)
> +{
> +/*
> + * DMI depends on EFI on arm64, and dmi_scan_machine() needs to be
> + * called early because dmi_id_init(), which is an arch_initcall itself,
> + * depends on dmi_scan_machine() having been called already.
> + */
> +
> +	dmi_scan_machine();
> +	return 0;
> +}
> +core_initcall(arm64_core_init);
> 

[PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[Leif Lindholm]

Hi Jon,

On Sat, Jan 17, 2015 at 12:57:38AM -0500, Jon Masters wrote:
> Hi Yi Li,

Yi has gone back to work inside Huawei, so probably did not receive
your messags.

> I would like some advice on the below patch. First, a little background.
> 
> I /may/ need to use SMBIOS provided data on ARMv8 systems to enumerate
> the number of physical underlying CPU sockets present.

This sounds like a very risky precedent to set. Hardware description for
the kernel comes in the form of DT or ACPI. SMBIOS is hardware
description for userland.

x86 added internal access to SMBIOS tables to be able to work around
known-bad firmware. I would say we're in a much better place today
with regards to people actually testing hardware with Linux than when
that happened, so would really like to avoid opening those floodgates
on ARM*.

The rest of this email is therefore assuming we are talking about a
temporary out-of-tree patch kept for development purposes until a
better solution can be devised to upstream.

> This is provided
> in one Type4 DMI structure per physical socket. Using that fact (such
> data is already provided by all of the reference ARMv8 server systems),
> and a variable interpretation of the CPU affinity data, we can refactor
> the topology.c code to understand threads vs cores vs sockets without
> getting confused by the extra levels of hierarchy for clusters.
> 
> I am going back over some older patches, including this one to
> understand the DMI port, and I notice that you call dmi_scan_machine
> from an early_initcall. This will run from the init thread, after we've
> done basic SMP setup in smp_prepare_cpus, which is where we stash
> cpu_topology data, which is after I already need DMI data available.

Yep.

> So. If I wanted this available prior to early_initcall time, would it be
> reasonable to follow e.g. x86 and move this early in the boot? I'm not
> necessarily going to ask to upstream such a change (since I expect to be
> able to solve the underlying problem I am looking to address in a
> different fashion soon), but first want to know if it would be
> reasonable to ask to do that anyway.

My suggestion would be to not try to over-engineer a patch not going
upstream. Move the call before smp_prepare_cpus() in init/main.c.

Or, if you can be fairly certain your SMBIOS table is covered by the
linear mapping, move the call to setup_arch().

> P.S. I'm not interested at all in replies pointing me to the existing DT
> cpu topology binding, which I am well aware of, but it does also not
> actually solve the problem I have :)

Not going to point, but perhaps the correct answer is to ensure the
information you need is provided via DT/ACPI. As your email hints at.

/
    Leif

[PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[Jon Masters]

On 01/17/2015 07:12 AM, Leif Lindholm wrote:
> Hi Jon,
> 
> On Sat, Jan 17, 2015 at 12:57:38AM -0500, Jon Masters wrote:
>> Hi Yi Li,
> 
> Yi has gone back to work inside Huawei, so probably did not receive
> your messags.

Good to know. I was at one point tracking all of the engineers involved
but it's getting harder to do that :)

>> I would like some advice on the below patch. First, a little background.
>>
>> I /may/ need to use SMBIOS provided data on ARMv8 systems to enumerate
>> the number of physical underlying CPU sockets present.
> 
> This sounds like a very risky precedent to set. Hardware description for
> the kernel comes in the form of DT or ACPI. SMBIOS is hardware
> description for userland.

Agreed. I don't actually want to set this precedent on ARM yet :)

> x86 added internal access to SMBIOS tables to be able to work around
> known-bad firmware. I would say we're in a much better place today
> with regards to people actually testing hardware with Linux than when
> that happened, so would really like to avoid opening those floodgates
> on ARM*.

Fair enough. I suspect we may get there one day, but I'm certainly not
going to try to move that along :) I have btw pushed every vendor to rev
their build information each time they build new firmware (when we build
the RH reference firmware for Mustang and - other boards I won't mention
on list - we do rev the version), and we'll require it in SBBR. That's
on my todo list for a clarification.

> The rest of this email is therefore assuming we are talking about a
> temporary out-of-tree patch kept for development purposes until a
> better solution can be devised to upstream.

Yup. I'm just exploring all of the options. Currently, there is no
reliable way to extract the exact number of sockets present, even with
the DT binding, and I need to know precisely how many sockets there are,
with this information correctly provided in the sysfs topology.

>> This is provided
>> in one Type4 DMI structure per physical socket. Using that fact (such
>> data is already provided by all of the reference ARMv8 server systems),
>> and a variable interpretation of the CPU affinity data, we can refactor
>> the topology.c code to understand threads vs cores vs sockets without
>> getting confused by the extra levels of hierarchy for clusters.
>>
>> I am going back over some older patches, including this one to
>> understand the DMI port, and I notice that you call dmi_scan_machine
>> from an early_initcall. This will run from the init thread, after we've
>> done basic SMP setup in smp_prepare_cpus, which is where we stash
>> cpu_topology data, which is after I already need DMI data available.
> 
> Yep.
> 
>> So. If I wanted this available prior to early_initcall time, would it be
>> reasonable to follow e.g. x86 and move this early in the boot? I'm not
>> necessarily going to ask to upstream such a change (since I expect to be
>> able to solve the underlying problem I am looking to address in a
>> different fashion soon), but first want to know if it would be
>> reasonable to ask to do that anyway.
> 
> My suggestion would be to not try to over-engineer a patch not going
> upstream. Move the call before smp_prepare_cpus() in init/main.c.

I guess. I don't like not overdoing things. You've met me right? ;)

> Or, if you can be fairly certain your SMBIOS table is covered by the
> linear mapping, move the call to setup_arch().

I thought about that. I think I can assume this, but I am not certain.
I'm going to ponder that. For now, the above (move before SMP setup) is
probably the way I'll go with it as a hackish kludge.

>> P.S. I'm not interested at all in replies pointing me to the existing DT
>> cpu topology binding, which I am well aware of, but it does also not
>> actually solve the problem I have :)
> 
> Not going to point, but perhaps the correct answer is to ensure the
> information you need is provided via DT/ACPI. As your email hints at.

Yep. I've multiple threads going to get this addressed properly.

Thanks Leif!

Jon.

[PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[Jon Masters]

On 01/17/2015 07:12 AM, Leif Lindholm wrote:

>> So. If I wanted this available prior to early_initcall time, would it be
>> reasonable to follow e.g. x86 and move this early in the boot? I'm not
>> necessarily going to ask to upstream such a change (since I expect to be
>> able to solve the underlying problem I am looking to address in a
>> different fashion soon), but first want to know if it would be
>> reasonable to ask to do that anyway.
> 
> My suggestion would be to not try to over-engineer a patch not going
> upstream. Move the call before smp_prepare_cpus() in init/main.c.
> 
> Or, if you can be fairly certain your SMBIOS table is covered by the
> linear mapping, move the call to setup_arch().

Note: actually dmi_early_remap is defined sufficiently on AArch64 today
to do the right thing creating a mapping or reusing the linear one.

Jon.

答复: [PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[liyi 00215672]

Hi Jon, Leif,

	I am reviving with phoenix.liyi at huawei.com :)

	Agreed with Leif, The DMI/SMBIOS data are available for user space not for kernel level on x86, which means if DMI has some bad descriptions, it should not affect the kernel boot normally.

	So ARM platform will do the same thing, DMI data just as a reference for system configuration, and don't depend them to boot the sytem. :)

	Thanks!

Yi

-----????-----
???: Jon Masters [mailto:jcm at redhat.com] 
????: 2015?1?17? 23:09
???: Leif Lindholm
??: msalter at redhat.com; catalin.marinas at arm.com; will.deacon at arm.com; linux-arm-kernel at lists.infradead.org; grant.likely at linaro.org; liyi 00215672; ard.biesheuvel at linaro.org
??: Re: [PATCHv4] arm64: dmi: Add SMBIOS/DMI support

On 01/17/2015 07:12 AM, Leif Lindholm wrote:
> Hi Jon,
> 
> On Sat, Jan 17, 2015 at 12:57:38AM -0500, Jon Masters wrote:
>> Hi Yi Li,
> 
> Yi has gone back to work inside Huawei, so probably did not receive 
> your messags.

Good to know. I was at one point tracking all of the engineers involved but it's getting harder to do that :)

>> I would like some advice on the below patch. First, a little background.
>>
>> I /may/ need to use SMBIOS provided data on ARMv8 systems to 
>> enumerate the number of physical underlying CPU sockets present.
> 
> This sounds like a very risky precedent to set. Hardware description 
> for the kernel comes in the form of DT or ACPI. SMBIOS is hardware 
> description for userland.

Agreed. I don't actually want to set this precedent on ARM yet :)

> x86 added internal access to SMBIOS tables to be able to work around 
> known-bad firmware. I would say we're in a much better place today 
> with regards to people actually testing hardware with Linux than when 
> that happened, so would really like to avoid opening those floodgates 
> on ARM*.

Fair enough. I suspect we may get there one day, but I'm certainly not going to try to move that along :) I have btw pushed every vendor to rev their build information each time they build new firmware (when we build the RH reference firmware for Mustang and - other boards I won't mention on list - we do rev the version), and we'll require it in SBBR. That's on my todo list for a clarification.

> The rest of this email is therefore assuming we are talking about a 
> temporary out-of-tree patch kept for development purposes until a 
> better solution can be devised to upstream.

Yup. I'm just exploring all of the options. Currently, there is no reliable way to extract the exact number of sockets present, even with the DT binding, and I need to know precisely how many sockets there are, with this information correctly provided in the sysfs topology.

>> This is provided
>> in one Type4 DMI structure per physical socket. Using that fact (such 
>> data is already provided by all of the reference ARMv8 server 
>> systems), and a variable interpretation of the CPU affinity data, we 
>> can refactor the topology.c code to understand threads vs cores vs 
>> sockets without getting confused by the extra levels of hierarchy for clusters.
>>
>> I am going back over some older patches, including this one to 
>> understand the DMI port, and I notice that you call dmi_scan_machine 
>> from an early_initcall. This will run from the init thread, after 
>> we've done basic SMP setup in smp_prepare_cpus, which is where we 
>> stash cpu_topology data, which is after I already need DMI data available.
> 
> Yep.
> 
>> So. If I wanted this available prior to early_initcall time, would it 
>> be reasonable to follow e.g. x86 and move this early in the boot? I'm 
>> not necessarily going to ask to upstream such a change (since I 
>> expect to be able to solve the underlying problem I am looking to 
>> address in a different fashion soon), but first want to know if it 
>> would be reasonable to ask to do that anyway.
> 
> My suggestion would be to not try to over-engineer a patch not going 
> upstream. Move the call before smp_prepare_cpus() in init/main.c.

I guess. I don't like not overdoing things. You've met me right? ;)

> Or, if you can be fairly certain your SMBIOS table is covered by the 
> linear mapping, move the call to setup_arch().

I thought about that. I think I can assume this, but I am not certain.
I'm going to ponder that. For now, the above (move before SMP setup) is probably the way I'll go with it as a hackish kludge.

>> P.S. I'm not interested at all in replies pointing me to the existing 
>> DT cpu topology binding, which I am well aware of, but it does also 
>> not actually solve the problem I have :)
> 
> Not going to point, but perhaps the correct answer is to ensure the 
> information you need is provided via DT/ACPI. As your email hints at.

Yep. I've multiple threads going to get this addressed properly.

Thanks Leif!

Jon.

答复: [PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[Jon Masters]

On 01/18/2015 08:27 PM, liyi 00215672 wrote:
> Hi Jon, Leif,
> 
> 	I am reviving with phoenix.liyi at huawei.com :)
> 
> 	Agreed with Leif, The DMI/SMBIOS data are available for user space not for kernel level on x86, which means if DMI has some bad descriptions, it should not affect the kernel boot normally.
> 
> 	So ARM platform will do the same thing, DMI data just as a reference for system configuration, and don't depend them to boot the sytem. :)
> 
> 	Thanks!

Thanks for the feedback! Looking forward to another visit to Shenzen soon :)

I'm afraid I think we'll need to use the socket information in DMI to
populate topology in the short term or for a vendor kernel or two. It's
important that certain tooling accurately account the number of sockets
present. It's awesome that ARM is going multi-socket. It's less awesome
to see the magic words "IMPLEMENTATION DEFINED". That always means
"abandon all hope ye who enter here". It'll need fixing in the form of a
rigidly defined standard.

I've just spent the weekend going through a variety of vendor tables and
manually validating/correcting them/harassing people to fix various ones
or convert to SMBIOS3. Depending upon how well this goes, we might be in
a position to have usable data for now. With a few sanity checks, we can
avoid using the data if it is incorrect. And in the medium term, we will
work on a better solution such as adding topology description to ACPI
tables. Then, we'll come back to this thread to see what is good
upstream, once we've some informed data about what is a practical solution.

Jon.

答复: [PATCHv4] arm64: dmi: Add SMBIOS/DMI support

[Jon Masters]

On 01/18/2015 10:30 PM, Jon Masters wrote:
> On 01/18/2015 08:27 PM, liyi 00215672 wrote:
>> Hi Jon, Leif,
>>
>> 	I am reviving with phoenix.liyi at huawei.com :)
>>
>> 	Agreed with Leif, The DMI/SMBIOS data are available for user space not for kernel level on x86, which means if DMI has some bad descriptions, it should not affect the kernel boot normally.
>>
>> 	So ARM platform will do the same thing, DMI data just as a reference for system configuration, and don't depend them to boot the sytem. :)
>>
>> 	Thanks!
> 
> Thanks for the feedback! Looking forward to another visit to Shenzen soon :)
> 
> I'm afraid I think we'll need to use the socket information in DMI to
> populate topology in the short term or for a vendor kernel or two. It's
> important that certain tooling accurately account the number of sockets
> present. It's awesome that ARM is going multi-socket. It's less awesome
> to see the magic words "IMPLEMENTATION DEFINED". That always means
> "abandon all hope ye who enter here". It'll need fixing in the form of a
> rigidly defined standard.
> 
> I've just spent the weekend going through a variety of vendor tables and
> manually validating/correcting them/harassing people to fix various ones
> or convert to SMBIOS3. Depending upon how well this goes, we might be in
> a position to have usable data for now. With a few sanity checks, we can
> avoid using the data if it is incorrect. And in the medium term, we will
> work on a better solution such as adding topology description to ACPI
> tables. Then, we'll come back to this thread to see what is good
> upstream, once we've some informed data about what is a practical solution.

Quick footnote that I have an *embarrassingly hackish* kludged version
of dmidecode that understands how to read SMBIOS3 tables from /dev/mem
and it's working on various hardware here (using it to sanity check
vendor tables and provide feedback). I'll share a patch if useful
off-list, but I'm waiting on Linaro to post the /sys/firmware/dmi patch
this week for the solution we'd like to see in the tools upstream.

Jon.