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 _______________________________________________ https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
