[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dmidecode] runtime update of smbios

From: Jonathan Zhang (Infra)
Subject: Re: [dmidecode] runtime update of smbios
Date: Mon, 7 Mar 2022 21:56:32 +0000

Hi Jean,

If all kernel/user space smbios consumers get the smbios data from 
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 
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?


From: Jean Delvare <>
Date: Monday, March 7, 2022 at 1:55 AM
To: <>
Cc: Jonathan Zhang (Infra) <>, Ron Minnich 
<>, Arthur Heymans <>
Subject: Re: [dmidecode] runtime update of smbios
Hi Jonathan,

On Thu, 3 Mar 2022 22:30:50 +0000, Jonathan Zhang via dmidecode-devel wrote:
> 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?

It does exactly that on Linux. If you loot at the main() function in
dmidecode.c, you'll find:

         * First try reading from sysfs tables.  (...)

        /* Next try EFI (ia64, Intel-based Mac, arm64) */

        /* Fallback to memory scan (x86, x86_64) */
        if ((buf = mem_chunk(0xF0000, 0x10000, opt.devmem)) == NULL)

That being said, I can't see how this relates to your initial question.
How the SMBIOS entry point address is found has nothing to do with the
table's contents being static or dynamic, and the DMI table seen and
exposed by the kernel is exactly the same as what dmidecode would get
from a memory scan.

Jean Delvare
SUSE L3 Support

reply via email to

[Prev in Thread] Current Thread [Next in Thread]