Here's a sample of the tables I have implemented at the moment.
Define the best subset to implement, complying with SMBIOS 2.4, and
collecting the data has been interesting, so these patches are
probably going to need some work.
I'm currently ignoring PCI slots, since I don't know much about them.
I've been trying to keep the data as minimal as possible, but would
certainly entertain adding information if it makes sense.
I'll try to post the patches here tomorrow after a brief code review.
Peace!
Andrew
# dmidecode 2.7
SMBIOS 2.4 present.
10 structures occupying 267 bytes.
Table at 0x000EA01F.
Handle 0x0000, DMI type 0, 24 bytes.
BIOS Information
 Vendor: Xen
 Version: 3.0
 Release Date: Mon May 1 17:06:51 EDT 2006
 Address: 0xE8000
 Runtime Size: 96 kB
 ROM Size: 64 kB
 Characteristics:
 BIOS Revision: 3.0
Handle 0x0100, DMI type 1, 27 bytes.
System Information
 Manufacturer: Xen
 Product Name: HVM domU
 Version: 3.0
 Serial Number: Not Specified
 UUID: 01234567-6012-0601-2360-120601234567
 Wake-up Type: Power Switch
 SKU Number: Not Specified
 Family: Not Specified
Handle 0x0300, DMI type 3, 13 bytes.
Chassis Information
 Manufacturer: Xen
 Type: Other
 Lock: Not Present
 Version: Not Specified
 Serial Number: Not Specified
 Asset Tag: Not Specified
 Boot-up State: Safe
 Power Supply State: Safe
 Thermal State: Safe
 Security Status: Unknown
Handle 0x0401, DMI type 4, 26 bytes.
Processor Information
 Socket Designation: CPU 1
 Type: Central Processor
 Family: Other
 Manufacturer: Intel
 ID: 46 0F 00 00 B7 FB E9 BF
 Version: Not Specified
 Voltage: Unknown
 External Clock: Unknown
 Max Speed: Unknown
 Current Speed: Unknown
 Status: Populated, Enabled
 Upgrade: Other
Handle 0x1000, DMI type 16, 15 bytes.
Physical Memory Array
 Location: Other
 Use: System Memory
 Error Correction Type: Other
 Maximum Capacity: 128 MB
 Error Information Handle: Not Provided
 Number Of Devices: 1
Handle 0x1100, DMI type 17, 21 bytes.
Memory Device
 Array Handle: 0x1000
 Error Information Handle: 0x0000
 Total Width: 64 bits
 Data Width: 64 bits
 Size: 128 MB
 Form Factor: DIMM
 Set: None
 Locator: DIMM 1
 Bank Locator: Not Specified
 Type: RAM
 Type Detail: None
Handle 0x1300, DMI type 19, 15 bytes.
Memory Array Mapped Address
 Starting Address: 0x00000000000
 Ending Address: 0x00007F003FF
 Range Size: 130049 kB
 Physical Array Handle: 0x1000
 Partition Width: 0
Handle 0x1400, DMI type 20, 19 bytes.
Memory Device Mapped Address
 Starting Address: 0x00000000000
 Ending Address: 0x00007F003FF
 Range Size: 130049 kB
 Physical Device Handle: 0x1100
 Memory Array Mapped Address Handle: 0x1300
 Partition Row Position: 1
Handle 0x2000, DMI type 32, 11 bytes.
System Boot Information
 Status: No errors detected
Handle 0x7F00, DMI type 127, 4 bytes.
End Of Table
On 5/16/06, B Thomas <bjthomas3@xxxxxxxxx> wrote:

I have been using the entire table for some time, with specific highlights
for BIOS, System, Module and Chassis. These contain relatively interesting
information about system IDs, manufacturer, version numbers, product name
and so forth. This has been of use to both management software, as well as
to your own eyeballs when you're trying to track something down to a
particular machine. I've included a sample of these items below (taken from
an HVM domain0 on a Dell 380).
 Clearly, much of this information is of use as applied to real hardware and
domain0, but there is probably an interesting subset for virtual machines in
domU. There's probably an interesting subset and analog for domainU
information. It will be interesting to see what you propose doing for the
domU visible DMI data. Do you intend to go as far as to include slots,
devices and ports ? Will you match what the ACPI tables report ?
 -b
 <BIOS Type="0" Item="2" Handle="0x0">
 <Vendor>Dell Inc. </Vendor>
 <Version>A06</Version>
 <ReleaseDate>01/09/2006</ReleaseDate>
 </BIOS>
 <System Type="1" Item="3" Handle="0x100">
<UUID>44:45:4c:4c:34:00:10:44:80:54:b5:c0:4f:4e:39:31</UUID>
 <Manufacturer>Dell Inc. </Manufacturer>
 <ProductName>Precision WorkStation 380 </ProductName>
 <SerialNumber>54DTN91</SerialNumber>
 </System>
 <Module Type="2" Item="4" Handle="0x200">
 <Manufacturer>Dell Inc. </Manufacturer>
 <ProductName>0G9322</ProductName>
 <Version> </Version>
 <SerialNumber>..CN7082161EI00M.</SerialNumber>
 </Module>
 <Chassis Type="3" Item="5" Handle="0x300">
 <Height>101U</Height>
 <Manufacturer>Dell Inc. </Manufacturer>
 <SerialNumber>54DTN91</SerialNumber>
 <AssetTag> </AssetTag>
 </Chassis>
 </DMTF>
On 5/15/06, Andrew Ball <anball@xxxxxxxxx> wrote:
>
 Is anyone else interested in SMBIOS tables for domU's? (These are the
things that dmidecode reads -- they're often used by systems
management software and occasionally used by drivers.)
I've been working on a patch for fully virtualized domU's for some
time now and am curious about who else might care about it and what
types they think make sense.
A lot of the types make very little sense, like system chassis, but
the system information one that contains the system UUID (universally
unique identifier) is crucial for supporting arbitrary OSes in HVM
domU's for some systems management software. The idea is to correlate
domU's with dom0's by UUID's of the domU's.
I'll try to send out the patches soon. I hope they're not too ugly to
stomach -- it's been difficult for me to make something like this
elegant.
Thanks for your help!
Andrew
--
=======================
Andrew D. Ball
anball@xxxxxxxxx
http://filebox.vt.edu/~anball1/
"Festina lente" $\approx$ "Make haste slowly"
 -- Caesar Augustus
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

--
=======================
Andrew D. Ball
anball@xxxxxxxxx
http://filebox.vt.edu/~anball1/
"Festina lente" $\approx$ "Make haste slowly"
 -- Caesar Augustus
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel