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

[Gabriel L. Somlo]

On Tue, Feb 18, 2014 at 11:21:33AM +0100, Gerd Hoffmann wrote:
> > Unfortunately, if we change the smbios in SeaBIOS, it will show up on
> > all machine types that use the new version of SeaBIOS.  We've had
> > issues with this type of change before as various OSes react
> > differently to the change.
> > 
> > Gerd, what's your take on this change?
> 
> I think we can do this in qemu, without touching seabios at all.  The
> currently used fw_cfg interface allows to pass both individual fields
> and complete tables.  In practice the individual fields interface is
> used for type0 and type1 table fields.  I think the only way to pass
> complete tables is 'qemu -smbios file=<pregenerated-blob-here>'.

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).

I then ran "dmidecode --from-dump" on the three binaries I collected,
and here's what I got:

  $ diff dmi_pc.txt dmi_mac.txt 
  2c2
  < Reading SMBIOS/DMI data from file dmidecode_pc.bin.
  ---
  > Reading SMBIOS/DMI data from file dmidecode_mac.bin.
  4c4
  < 10 structures occupying 298 bytes.
  ---
  > 11 structures occupying 326 bytes.
  29a30,43
  > Handle 0x0200, DMI type 2, 15 bytes
  > Base Board Information
  >       Manufacturer: Bochs
  >       Product Name: Not Specified
  >       Version: Not Specified
  >       Serial Number: Not Specified
  >       Asset Tag: Not Specified
  >       Features:
  >               Board is a hosting board
  >       Location In Chassis: Not Specified
  >       Chassis Handle: 0x0300
  >       Type: Motherboard
  >       Contained Object Handles: 0
  > 
  73c87
  < Handle 0x1100, DMI type 17, 21 bytes
  ---
  > Handle 0x1100, DMI type 17, 27 bytes
  85a100,104
  >       Speed: Unknown
  >       Manufacturer: Not Specified
  >       Serial Number: Not Specified
  >       Asset Tag: Not Specified
  >       Part Number: Not Specified

This looks as expected (we have a new Type 2 entry, and the Type 17
entry now has version 2.3 fields where it didn't use to before).

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.
 
> If seabios finds a table provided by qemu it used it, otherwise it
> (possibly) generates its own.  So we can smoothly switch over to qemu,
> table-by-table.  You can have qemu provide type2+type17 tables, and
> leave everything else as-is.  And when doing it in qemu it is easy to do
> it for new machine types only.

Sending a patch against QEMU would have definitely been my first
choice, by a wide margin :) But after studying the hw/i386/smbios.c
source file in QEMU for a while, I walked away with the impression
that all it really tries to do is edit a few of the Type 0 and Type 1
fields, and that the hand-over logic between QEMU and SeaBIOS is not
ready for prime time yet.

So I sent the patch to SeaBIOS, where it seems to do what I want it to :)

I could try to hack at the QEMU smbios source file to try to find
where the problem lies (at least why handover to SeaBIOS doesn't work
as expected), but I'm not sure providing command line flags for
inputting each record type individually is a scalable way to move
forward.

Perhaps if there were a DMI/SMBIOS compiler (the reverse action of
"dmidecode --from-dump", something that would take a text "source"
table and generate a .bin from it), we could focus on getting the
"-smbios file=<foo>" bit working correctly, and we could provide
instructions in the docs on how users can build their own smbios
tables.

But I couldn't find anything out there that would "compile" a smbios
table from some type of human-readable (ascii) form...

Any thoughts ?

Thanks,
--Gabriel

PS. I tried the patched SeaBIOS (with v2.3 type17 and added type2) on
XP, Windows7, and Linux, and all of them seemed happy and none of them
seemed to mind... Just sayin' ;)