Re: [Qemu-devel] [PATCH v2, Ping] SMBIOS: Upgrade Type17 to v2.3, add Type2

[Laszlo Ersek]

On 02/18/14 22:08, Laszlo Ersek wrote:
> On 02/18/14 20:17, Gabriel L. Somlo wrote:
>> On Tue, Feb 18, 2014 at 11:21:33AM +0100, Gerd Hoffmann wrote:
> 
>> Using Fedora 20 live, I collected the SMBIOS table from the guest
>> using "dmidecode --dump-bin", with the unpatched SeaBIOS
>> (dmidecode_pc.bin), SeaBIOS with my patch applied (dmidecode_mac.bin),
>> and again with unpatched SeaBIOS but with "-smbios file=dmidecode_mac.bin"
>> on the QEMU command line (dmidecode_cmdline.bin).
> 
> [...]
> 
>> However, when I compare unmodified SMBIOS against what I get when
>> supplying the patched binary table via command line, I get this:
>>
>>   $ diff dmi_pc.txt dmi_cmdline.txt 
>>   2c2
>>   < Reading SMBIOS/DMI data from file dmidecode_pc.bin.
>>   ---
>>   > Reading SMBIOS/DMI data from file dmidecode_cmdline.bin.
>>   4c4
>>   < 10 structures occupying 298 bytes.
>>   ---
>>   > 11 structures occupying 657 bytes.
>>   108,109c108,120
>>   < Handle 0x7F00, DMI type 127, 4 bytes
>>   < End Of Table
>>   ---
>>   > Handle 0x5F4D, DMI type 95, 83 bytes
>>   > Unknown Type
>>   >       Header and Data:
>>   >               5F 53 4D 5F 32 1F 02 04 4B 00 00 00 00 00 00 00
>>   >               5F 44 4D 49 5F D2 46 01 20 00 00 00 0B 00 24 00
>>   >               00 18 00 00 01 02 00 E8 03 00 08 00 00 00 00 00
>>   >               00 00 00 04 01 00 FF FF 42 6F 63 68 73 00 42 6F
>>   >               63 68 73 00 30 31 2F 30 31 2F 32 30 31 31 00 00
>>   >               01 1B 00
>>   >       Strings:
>>   >               ....
>>   > 
>>   > Invalid entry length (0). DMI table is broken! Stop.
>>
>> No Type 2, no extra fields for Type 17, and a corrupt table to boot.
> 
> I had tested this qemu interface with my OVMF SMBIOS patches. It works.
> (I used a Type 3 table.)
> 
> The problem in this case is that you can't just pass in a raw dump from
> dmidecode. You need to prefix it with "smbios_header":
> 
> struct smbios_table {
>     struct smbios_header header;
>     uint8_t data[];
> } QEMU_PACKED;
> 
> struct smbios_header {
>     uint16_t length;
>     uint8_t type;
> } QEMU_PACKED;
> 
> You need to set "type" to 1 (SMBIOS_TABLE_ENTRY), and set "length" so
> that it covers the entire "smbios_table" struct (ie. both header and
> payload, where payload is your SMBIOS table). "length" is little endian.

Oh wait, scratch that, qemu should do this for you.

But, I retested the thing (with my original Type 3 file), and it still
seems to work.

-smbios file=/home/virt-images/smbios/type3

000000 03 14 00 03 01 01 00 00 00 03 03 03 02 00 00 00
000010 00 00 00 00 52 65 64 20 48 61 74 00 00

Dumped in the OVMF guest:

Handle 0x0000, DMI type 3, 20 bytes
Chassis Information
        Manufacturer: Red Hat
        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
        OEM Information: 0x00000000
        Height: Unspecified
        Number Of Power Cords: Unspecified

What was the exact command line you used?

... Ah, I think I understand. When you issued dmidecode --dump-bin, that
dumped *all* of the tables. (--dump-bin is mutually exclusive with
--type.) You can't pass multiple tables with one '-smbios file=XXX qemu
option. You need separate binary dumps (one per table), and should pass
them with one -smbios file=XXX option each.

Thanks
Laszlo