Re: [Xen-devel] interest SMBIOS on domU's

["Andrew Ball" <anball@xxxxxxxxx>]

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