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' ;)