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