SMBIOS in Virtualization
SMBIOS, System Management BIOS, is a specification, not a hardware.
SMBIOS addresses how motherboard and system vendors present management information about their products in a standard format by extending the BIOS interface. It eliminates the need for the operating system to probe hardware directly to discover what devices are present in the computer.
The SMBIOS specification is produced by the Distributed Management Task Force (DMTF). The SMBIOS specification is available from the organization’s website.
SMBIOS was originally known as Desktop Management BIOS (DMIBIOS), since it interacted with the Desktop Management Interface (DMI).
This specification was originally designed for Intel processor architecture systems. Now it supports more, including:
- IA-32 (x86)
- x64 (x86–64, Intel64, AMD64, EM64T)
- Intel® Itanium® architecture
- 32-bit ARM (Aarch32)
- 64-bit ARM (Aarch64)
Interpreting SMBIOS
The management information provided by SMBIOS is in the form of tables. The main part of the SMBIOS specification is the definition of all the tables.
SMBIOS defines an Entry Point Structure for the starting point to access and understand all the tables.
On non-UEFI systems, the SMBIOS Entry Point structure can be at any location between address 0x000F0000h and 0x000FFFFFh. The location is not fixed. To find out the Entry Point, the application software need to search for an `anchor-string` to recognize where the Entry Point is.
On UEFI systems, the SMBIOS Entry Point structure can be located by looking for an EFI Configuration Table with a specified GUID:
- For 32-bit SMBIOS, the GUID is “SMBIOS_TABLE_GUID, {EB9D2D31–2D88–11D3–9A16-0090273FC14D}”
- For 64-bit SMBIOS, the GUID is “SMBIOS3_TABLE_GUID, {F2FD1544–9794–4A2C-992E-740 E5BBCF20E394}”
The Entry Point structure of 32-bit and 64-bit SMBIOS are significantly different. The 2 versions of the structure are described in Chaper 5 of the specification (v3.0.0).
Behind the Entry Point structure are various tables/structures carrying different management information.
In SMBIOS specification version 3.0.0, totally 45 types of table/structure are defined, like (not a complete list):
0. BIOS Information (Type 0)
1. System Information (Type 1)
2. Baseboard (or Module) Information (Type 2)
3. System Enclosure or Chassis (Type 3)
4. Processor Information (Type 4)
……
SMBIOS on AArch64
For the latest version (v3.0.0), the SMBIOS specification itself doesn’t have any gap on AArch64 architecture. And the Arm Base Boot Requirement requires SMBIOS.
However, SMBIOS is not practical on AArch64 in the case of non-UEFI. The spec requires the Entry Point Structure be placed at somewhere beginning from physical address 0x000F0000h ~ 0x000FFFFFh. But on AArch64 it’s not feasible. Different machines can have different memory layout. It’s very possible that there is not any RAM in the required range.
For this reason, non-UEFI use case is not enabled in Linux kernel by default.
In kernel, the non-UEFI case requires the configuration item “CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK”, but it cannot be enabled on ARM architectures, except you add it explicitly in “arch/arm64/Kconfig”.
The code to handle the Entry Point for non-UEFI and UEFI cases is here.
SMBIOS in Virtualization
On Cloud Hypervisor, SMBIOS has been supported on X86_64, but not on AArch64 so far (release 23.0). And not all table types are supported. Support was only added on request.
The latest added item was the serial_serial field of System Information (Type 1) table. To test it, you can run the VMM like:
# cloud-hypervisor [... irrelevant options ignored ...] --platform serial_number=a=b;c=dAfter the guest VM is started, you can find the management information you have assigned (“a=b;c=d”) in system file “/sys/class/dmi/id/product_serial”.
On Qemu, the way to set the same information into SMBIOS is like:
# qemu-system-aarch64 [... irrelevant options ignored ...] -smbios type=1,serial=xxxxDon’t forget, you need to boot from firmware, not direct kernel.
