search

riscv-non-isa / riscv-brs

The Boot and Runtime Services (BRS) specification provides the software requirements for system vendors and Operating System Vendors (OSVs) to interoperate with one another by providing expectations for the Operating System (OS) to utilize in acts of device discovery, system management, and other rich operations provided in this specification.
https://jira.riscv.org/browse/RVG-48
Creative Commons Attribution 4.0 International
41 stars 13 forks source link

How to collect SMBIOS type 44 information #99

Open xypron opened 10 months ago

xypron commented 10 months ago

Firmware typically only runs on a single hart. The SBI Hart State Management extension was introduced to allow running on a single hart and let the OS wake up all other harts.

On a system with socketed CPUs the only way to determine the information in the SMBIOS type 44 table would be to wake up each hart and call the SBI Base Extension to read mvendid, marchid, mimpid for the respective hart. This would unnecessarily waste boot time.

In a system with hot plugable CPUS the content of the table will be of no value because it may not represent the current state.

The smbios information is not only inaccurate it is also redundant as /proc/cpuinfo already provides it. We should neither require nor suggest providing this table.

andreiw commented 10 months ago

As far as collecting the data, there are many ways this could be done. The most obvious one would be "collecting at compile time", as the hart register state is well known for SoCs. So this only starts mattering on actual socketed designs, where boot time is not problem (consider DDR training time, or the amount of time a typical server waits around for various components to initialize, the SCP or BMC). As far as collecting such information, it could a) be collected by M mode firmware and passed to the UEFI (via DT, via HOB, etc) b) directly queried by S-Mode UEFI via HSM, which is not going to take a significant amount of time (relative to everything else involved), and is typical of x86 and Aarch64 server designs.

SMBIOS is not redundant to /proc/cpuinfo, at the very least because the ecosystem we're trying to build here is not Linux-specific. Moreover, /proc/cpuinfo is a userspace mechanism, where as SMBIOS tables can be used by supervisor/hypervisor components.

You're also missing the general value prop behind the SMBIOS tables - these describe inventory, field-replaceable units/parts. They don't generally describe aspects necessary to configure the system. The CPU fields actually end up being a bit of an exception here, and it's something that was (to a degree) exacerbated by AArch64 when the SoC ID (for errata) mechanism was introduced.

xypron commented 10 months ago

Compiling the information into the firmware would imply a new firmware for every new mimpid (I would assume that matches a CPU stepping).

andreiw commented 10 months ago

Compiling the information into the firmware would imply a new firmware for every new mimpid (I would assume that matches a CPU stepping).

It's highly likely stepping differences will mean updates to the really low level M-mode fw. Again, you don't have to hard code, I'm just saying it's a possibility.

ved-rivos commented 9 months ago

Other ways it could be carried is a data file corresponding to that machine.

andreiw commented 7 months ago

I'm not sure any of the above discussion is useful in practice in a guidance document. If you feel like it is, please work on a pull request. If not, please close the issue off.