Re: [dmidecode] runtime update of smbios

[Jean Delvare]

Hi Jonathan,

On Mon, 7 Mar 2022 21:56:32 +0000, Jonathan Zhang (Infra) wrote:
> If all kernel/user space smbios consumers get the smbios data from 
> /sys/firmware/dmi,
> the data in /sys/firmware/dmi could be updated by kernel/firmware as part of 
> hot plug
> and hog remove handling procedure; and then the smbios consumers would get 
> updated
> info following hot plug and hot remove event.
> 
> In this case, the data in /sys/firmware/dmi is out-of-sync with the data 
> provided at boot time
> (such as the data in the 0xF0000 memory region); but this is okay.
> 
> What do you think?

I can't see how this could be implemented reliably and consistently.
The kernel doesn't know for sure which DMI entry corresponds to what
physical slot.

For device card slots (type 9), we could use the Segment, Bus and
Device/Function Number fields for slot identification, assuming that the
hotplug event includes that information. This would however assume that
the BIOS has filled out this information properly even for empty slots.
In my experience this is not always the case.

For memory module slots (type 17), all we have are the Device Locator
and Bank Locator strings, which can be set to anything (if set at all).
I don't know much about memory hot-plug but I can think of any
possibility to map these strings to a memory hot-plug event.

Then, even if this first problem was solved somehow, we would be facing
an equally complex problem with the record details. How would you
figure out the memory type, type details, speed, manufacturer, serial
number etc.? For this you would need to access the SPD EEPROMs over the
SMBus. While there is preliminary support for that in the kernel, there
are many situations where we just don't know how to access these
EEPROMs.

Even if we managed to do that, we'd face yet another issue, which is
that DMI strings are included in the DMI table after the record they
belong too, so if you want to add a string (or change it to something
longer than it originally was), you first have to make room for it.
This means making the overall DMI table larger and moving all the
following records. This can't be done in place as we have no guarantee
that there's enough room where the table was originally mapped by the
BIOS. So we would have to make our own copy of the DMI table. This has
a significant memory cost. Plus the BIOS wouldn't know about that, and
would keep updating the Log Change Token (the only field of the DMI
table which can change at runtime according to the specification) at
the original memory location, so we would no longer see it.

As a summary, I see many problems with your proposal, and some of them
don't seem to be solvable at all. In my opinion, if we want the DMI
table to be updated on hot-plug events, this must be added to the
SMBIOS specification first, and implemented with the help of the BIOS.

I believe it is more reasonable to accept that DMI data reflects the
status at boot time. If you need runtime information, there are other
tools for that (such as lspci).

-- 
Jean Delvare
SUSE L3 Support