On Mon, Apr 07, 2014 at 10:49:54AM -0400, Gabriel L. Somlo wrote:
On Mon, Apr 07, 2014 at 10:14:36AM -0400, Kevin O'Connor wrote:
How about having QEMU produce the smbios table with a dummy type0 table and then both seabios and ovmf can replace the type0 table if desired. After all, if OVMF is splitting the blob into tables, it can just as easily replace type0 as append it.
This way, the QEMU output is technically complete. And if someone wishes to code up SeaBIOS to do the type0 replace (I'm not convinced it's even necessary) then at least that SeaBIOS code could be used on coreboot as well.
OK, so as far as I'm concerned, it's down to two alternatives:
- I create a full blob, starting with the anchor/entrypoint, and
followed by a (dummy) type 0, type 1, etc, etc. all the way to the type 127 end marker. Pass that in via fw_cfg, and each BIOS is then responsible for editing type 0, overwriting it with appropriate values.
I like this very much :) except for a serious discomfort with the idea of imposing an additional "convention" on the size (and choice of) strings included with the type0 table, beyond the smbios spec.
I agree that was too ugly. What I'm proposing now is that QEMU produce a valid type0 table (with strings populated, but no special padding) along with all the other tables (up to and including type 127).
Then SeaBIOS and OVMF can either pass this on exactly as is, or they can modify the table to replace type0.
This is a few more lines of code for SeaBIOS (to replace type0 instead of just patching it), but it has the advantage that QEMU developers know they must produce a valid smbios table according to the specs and the firmware developers know they will get a valid smbios table (according to the specs) and know they must ultimately produce a valid smbios table.
So, I'm suggesting QEMU produce two new fw_cfg files: an anchor file with the valid anchor table (the address pointer can be just set to zero), and an smbios table file with the complete set of smbios tables formatted according to the smbios spec. SeaBIOS can then use the existence of one of these new files to determine if it should deploy (and optionally modify) them or if it should use the old smbios generation code.
-Kevin