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
|
Home