On Tue, Apr 01, 2014 at 02:47:27PM -0400, Gabriel L. Somlo wrote:
On Tue, Apr 01, 2014 at 05:47:09PM +0200, Laszlo Ersek wrote:
bit 2 of the BIOS Characteristics Extension Byte 2 (7.1.2.2) is set, for "Enable Targeted Content Distribution".
In OVMF, the same byte has the following bits set:
Bit 3 -- UEFI Specification is supported. Bit 4 -- The SMBIOS table describes a virtual machine. (If this bit is not set, no inference can be made about the virtuality of the system.)
I have nothing against bit 2 (I didn't include it because I had no clue what it meant, but we can certainly set that bit down the road). Bit 3 would be wrong for SeaBIOS, and it would be wrong to leave clear for OVMF. Bit 4 would be wrong for SeaBIOS (as a static default), but is correct (and very nice, although not necessary) for OVMF.
I can add an extra command line option for type 0 defaults (e.g. "char_ext" but we can pick a better name):
"-smbios type=0,vendor='foo',version='x.y',char_ext=4"... and make the user responsible for supplying the correct value if/when they wish to override the defaults. I'll do that in the v5 patch set I'm working on right now :)
As an aside, I think in the end it doesn't matter much if we supply individual field defaults or full tables for *optional* types such as type 0. I just like to generate full tables across the board to keep reusing the same code, rather than leave the individual-field logic in just for this one table type...
From the conversation so far, it seems to me that:
type 0 is best left to the BIOS (user overrides via command line at their own risk)
therefore, the maximum granularity of QEMU-generated elements should be full tables of a given type, and not the full SMBIOS blob at once (other mechanisms to allow the BIOS to insert its own type 0 welcome, but so far this seems the most straightforward one).
I don't agree - I think ultimately we want QEMU to generate the full SMBIOS table and pass it to the firmware via the romfile_loader mechanism. The only thing that has been raised as an issue with this is one bit in the smbios table (UEFI support). For this one bit, I think QEMU can just put together a sane default and the firmware can patch up the one bit (either manually or via a new romfile_loader command).
this means the smbios structure header has to be left up to the BIOS
the BIOS is then responsible for setting the smbios spec version (2.4 for SeaBIOS, 2.7.1 for OVMF).
On that last point, at least Linux seems to be OK with individual type tables having a higher version than the structure header; i.e., dmidecode works fine when e.g. the structure header says 2.4 but the type 4 cpu record is 2.6. I'll test on Windows and OS X as well, and post my results here.
My one remaining question is: how do we get the BIOS to *not* generate a certain table type that's being left out on purpose by QEMU ?
I'm talking here of type 20, which is no longer required as of spec v2.5, and which would unnecessarily complicate things if/when more than two E820_RAM memory areas are present...
The above are good examples why I think QEMU should be the sole owner of the SMBIOS.
-Kevin