On 04/01/14 23:28, Gabriel L. Somlo wrote:
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) ?
Right now, OVMF can accept individual fields, or table-at-a-time blobs, via fw_cfg.
The internal interface (EFI_SMBIOS_PROTOCOL) expects one table at a time (for which table-at-a-time blobs are a perfect match).
If qemu gives OVMF a complete, concatenated dump of all tables, I'll have to split that up into individual tables, and install those one by one.
qemu --[fw_cfg]--> OVMF platform code --[EFI_SMBIOS_PROTOCOL]--> edk2 "some" format: strictly per-table - field patch - per-table blob - complete dump?
I think that concatenating table-at-a-time blobs in SeaBIOS is easier than parsing & splitting a complete dump into tables in OVMF.
Kevin might disagree of course :)
Thanks Laszlo