Re: [dmidecode] runtime update of smbios

[Arthur Heymans]

Hi

So the smbios spec indicates that it should be static:
"The information that is present in the table-based structures is boot-time
static, and SMBIOS consumers
should not expect the information to be updated during normal system
operations, except for the Log
Change Token if implemented"

So is this about the Log Change Token? It's not super clear to me what that
means from the spec.

So currently the spec allows 2 ways to provide smbios to the OS:
- Legacy 0xf0000
- UEFI runtime services

Some platforms don't implement UEFI, (e.g. coreboot), but still need a
flexible way to pass it to the OS.
With ACPI there was a similar problem but it was fixed the following way on
Linux:
e6e094e053af75cbc164e950814d3d084fb1e698 (x86/acpi, x86/boot: Take RSDP
address from boot params if available)
implements a simple way to pass the ACPI RSDP via the Zero Page.

Btw on other architectures there is an even bigger problem with the legacy
0xf0000 not being available,
which mandates UEFI to be able to use smbios. This should not be the case.
Should the smbios offset be passed via devicetree on non-x86 platforms (
https://www.devicetree.org/)?

Arthur Heymans



9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  arthur.heymans@9elements.com
Phone:  *+49 234 68 94 188 <+492346894188>*
Mobile:  *+32 478499445*

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Eray Basar

Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy>


On Thu, 3 Mar 2022 at 23:30, Jonathan Zhang (Infra) <jonzhang@fb.com> wrote:

> Hi,
>
>
>
> Today smbios table is generated at boot time, as a static blob in reserved
> memory region.
>
> Some of the info becomes stale following hot add/remove events which
> becomes
>
> common nowadays.
>
>
>
> I wonder if there is any alternative, or some discussions/plan in progress
> to solve this
>
> problem? Any feedbacks/pointers are appreciated.
>
>
>
> One idea is to make sysfs (/sys/firmware/dmi/) to be the source
>
> of truth for all kernel and user space code which need to
>
> consume smbios data. It looks like dmidecode hard codes
>
> the memory region base 0xF0000, why don’t it pick up from
> /sys/firmware/dmi?
>
>
>
> Thank you,
>
> Jonathan
>
>
>