arm64: dmi: Add SMBIOS/DMI support

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 <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---

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/kernel/efi.c +13 -0

+
+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);

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.

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

Hi Jon,

Quoted 1 line · Jon Masters

Hi Yi Li,

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

Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

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().

Quoted 3 lines

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.

Hi Jon,

Quoted 1 line · Jon Masters

Hi Yi Li,

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

Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

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().

Quoted 3 lines

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.

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!

Quoted 9 lines · 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.

Quoted 6 lines

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().