SMBIOS Support for Solaris x86

For the past few years, Sun engineering has been hard at work making the x86 platform a first-class citizen. In case you've been napping, some of the highlights included:

Meantime, there's a bunch of great engineering work going on behind the scenes to continue to enhance our x86 offerings. Three of the bigger things we've been making progress on are There are also many smaller pieces that we're putting together, steps that improve the day-to-day quality of life for users, developers, and system administrators. Over the weekend, I integrated another piece: Solaris support for the x86 System Management BIOS (SMBIOS). First I'll talk about why we did this and why it's important, and then I'll spend the remainder of the blog discussing a bit about the design and code for you OpenSolaris propeller-heads. These changes will be visible in OpenSolaris and Solaris Express as part of Build 23.

What is SMBIOS?

System Management BIOS (SMBIOS) is a data structure exported by most modern BIOSes on x86 platforms, including those currently produced by Sun. SMBIOS is an industry-standard mechanism for low-level system software to export hardware configuration information to higher-level system management software. The SMBIOS data format itself is defined by the Distributed Management Task Force (DMTF). Refer to dmtf.org if you want to read a copy of the specification itself.

The SMBIOS image consists of a table of structures, each describing some aspect of the system software or hardware configuration. The content of the image varies widely by platform and BIOS vendor, and may not exist at all on some systems. However, it is the only known mechanism for system software to obtain certain information on x86 systems. A simple example of information found in SMBIOS is the actual name of the platform (e.g. Sun Microsystems v40z), the BIOS vendor, version, and release date. More advanced records describe the DIMM slots in the machine, their labels (i.e. how you can locate them if you crack open the case), and various other slot types and properties.

Not much attention has been paid to SMBIOS: Windows uses it to get the system serial number and is beginning to emphasize its importance to hardware vendors, and the Linux dmidecode utility (DMI was the original name of the SMBIOS spec) has been available for some time to dump it all out in human-readable form for hackers and administrators who wish to peek at some of the details of the underlying hardware on their platform.

SMBIOS and Solaris

The work I integrated this weekend into Solaris provides an equivalent decoding utility for SMBIOS (albeit with some nicer features), but is actually a stepping stone to connecting this information with the new Fault Management features we introduced in Solaris 10. As such, I wanted to provide a much richer environment for dealing with SMBIOS. Specifically, we're working on the first collection of Fault Management features for x64 right now, part of our broader effort to implement Predictive Self-Healing in Solaris. For x64 platforms, the first set of features will include automated diagnosis and fault isolation for Opteron CPU and Memory errors and for our PCI-E stack, all connected to our standardized self-healing administration model, messaging, and knowledge article web. SMBIOS is a tiny piece of this puzzle: it gives us the ability to label self-healing diagnosis messages with the appropriate chassis serial number you need to provide if you file a service call, and allows us to properly identify faulty FRUs you need to replace with the labels that will let you easily locate and remove them from your box.

The initial SMBIOS support provides the following new features:
  • A common set of Solaris APIs to decode and examine SMBIOS images. The common source is compiled both into a new user library, libsmbios, and into the kernel itself. The APIs provide a simplified programming model for accessing SMBIOS, converting the string table indices to string pointers, sanitizing addresses, and generally handling all the bizarre implementation artifacts of the data format itself.

  • A new smbios(1M) utility to permit developers and administrators to examine SMBIOS images either exported by the system or stored in a file on disk. You can also copy your SMBIOS image out to a file (this might be useful for building a catalog of machine configurations, and was very useful to me in developing automated test software for this whole thing).

  • A new smbios(7D) character special device that exports a snapshot of the current system's SMBIOS image, taken at the time the system boots.

  • An implementation of prtdiag(1M) (long present on SPARC Solaris) for Solaris x86 platforms that displays the x86 platform name and summary hardware information using SMBIOS.


Here is the usage for the new smbios(1M) utility:
Usage: smbios [-BeOsx] [-i id] [-t type] [-w file] [file]

        -B disable header validation for broken BIOSes
        -e display SMBIOS entry point information
        -i display only the specified structure
        -O display obsolete structure types
        -s display only a summary of structure identifiers and types
        -t display only the specified structure type
        -w write the raw data to the specified file
        -x display raw data for structures


And here is some output from the x86 prtdiag using SMBIOS:
System Configuration: Sun Microsystems   W1100z/2100z
BIOS Configuration: Sun Microsystems R01-B2 S0 10/12/2004

==== Processor Sockets ====================================

Version                          Location Tag
-------------------------------- --------------------------
AMD Opteron(tm)                  CPU1
AMD Opteron(tm)                  CPU2

==== Memory Device Sockets ================================

Type    Status Set Device Locator      Bank Locator
------- ------ --- ------------------- --------------------
DDR     empty  1   DIMM1               Bank 0
DDR     empty  1   DIMM2               Bank 0
DDR     in use 2   DIMM3               Bank 1
DDR     in use 2   DIMM4               Bank 1
DDR     empty  5   DIMM5               Bank 2
DDR     empty  5   DIMM6               Bank 2
DDR     in use 6   DIMM7               Bank 3
DDR     in use 6   DIMM8               Bank 3

==== On-Board Devices =====================================

==== Upgradeable Slots ====================================

ID  Status    Type             Description
--- --------- ---------------- ----------------------------
0   unknown   AGP 8X           AGP8X PRO 110
1   available PCI-X            PCIX1-100MHZ
0   unknown   PCI-X            PCIX2-133MHZ
3   available PCI-X            PCIX3 100 ZCR
0   unknown   PCI-X            PCIX4 100
0   unknown   PCI-X            PCIX5 100

SMBIOS Subsystem Design

One of the most important principles in system software design (or really any large-scale software effort) is what I refer to as leverage, which is my shorthand for locating high-leverage subsystems that form the basic building blocks of the system, and really engineering these things right such that a wide variety of consumers can be easily and flexibly built on top.

For example, in Solaris, we have an incredibly flexible virtual memory allocator built out of two layers, vmem and kmem. The introduction of vmem in Solaris 8 allowed us to delete about 50 special-purpose non-scalable memory allocation subsystems in Solaris, greating simplifying the kernel, while at the same time improving the scability, performance, and debuggability of all those new clients. That's leverage.

File and data formats are another place where investing in a high-leverage subsystem is really worthwhile. The leverage points I wanted for SMBIOS were:
  • common API for both userland and kernel consumers built from same source code
  • ability to access SMBIOS from file, memory buffer, or pseudo-device
  • ability to easily maintain and extend the human-readable decoding


Here is a diagram of the new subsytem, showing the source code, binaries, and how the layering works:

The source code in /usr/src/common/smbios/ contains the code to initialize an SMBIOS snapshot from a file or in-memory buffer, and provide a set of common programming APIs for consuming software. This code is compiled twice: once to form an in-kernel SMBIOS subsystem, and a second time to form the bulk of the userland libsmbios library. The library and kernel each provide a small set of glue routines in a file named smb_subr.c, and then each provide some basic discovery routines. For the kernel, discovery is performed by mapping the BIOS's physical memory region and scanning for the SMBIOS table. For the userland library, discovery is performed either by opening a file or a device, or scanning a device which exports the BIOS's physical memory region.

The kernel then implements a small pseudo-driver, smbios(7D), which simply takes the SMBIOS data discovered at boot time and exports it for use by the library. In userland, the smbios(1M) utility provides generic data display for developers, and an x86 prtdiag is provided which also leverages the library. In the kernel, the IPMI bmc(7D) driver uses the in-kernel subsystem to discover the local Baseboard Management Controller, for use with ipmitool. As you might expect, the original IPMI driver implementation had its own private, buggy, non-leveraged SMBIOS decoder, and all that just got deleted.

One final trick to achieve maintainability is that I wrote a shell script that auto-generates C source to convert the integers used in various SMBIOS fields into the corresponding human-readable strings by simply grabbing the comments next to the appropriate #defines in the new smbios.h. As such, there's no way that a developer can add or modify our definition of the format and forget to update the smbios(1M) output.

You can find out more about Fault Management in Solaris from our OpenSolaris community or by posting a question to the discussion forum. If you're interested in looking at the source code or experimenting with the interfaces, you can use the OpenSolaris Source Browser to locate things. It will take a week or so for the code to propagate into the Source Browser's snapshot of the OpenSolaris tree.

$q

Technorati Tag:
Technorati Tag:
Comments:

And of course the first thing I find out is that according to smbios, I have no cpus in my laptop... I guess I need to go to the manufacturer's website and find out what engineering magick they've performed.

Posted by James McPherson on August 28, 2005 at 09:46 PM PDT #

This is very nifty stuff... I really like the level of detail provided here. Though I can't help but wonder if the -BeOsx options were named alphabetically to play on BeOS and OS X ;) (I look too hard sometimes :D). I'm definitely looking forward to seeing this shape into something used in FMA. It will be cool to see something like `DIMM in slot 3 (4th slot from the right side of the chassis) is bad.' (or something of that order -- I'm sure the actual message would be better than whatever I come up with at 11:45PM :))

Posted by Devon H. O'Dell on September 08, 2005 at 04:52 PM PDT #

can it work well on solaris 9 x86?any binary packge for solaris 8,9 and 10 available? thanks!

Posted by steven.wang on December 05, 2005 at 10:24 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

mws

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks