On Tue, Apr 01, 2014 at 04:28:32PM -0400, Kevin O'Connor wrote: > > 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.
Assuming all relevant QEMU maintainers are OK with the idea of creating a full SMBIOS blob (with e.g. type 0 defaulting to the relevant SeaBIOS values, override-able to fit some different bios, e.g. OVMF), would you take a patch to check for this blob in smbios_setup() (in SeaBIOS src/fw/smbios.c) ? Right now, it's either individual fields or table-at-a-time blobs only, AFAICT. Assuming "yes", would OVMF accept a similar patch (unless it's already set up to receive such a blob, I forget whether that came up earlier in the thread) ? Thanks, Gabriel -- In Soviet Russia, problem divide-and-conquer YOU ;)