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:
1. 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.
2. I create a third fw_cfg smbios "type" for the entry point structure.
The BIOS (e.g. smbios_setup() in SeaBIOS) checks for the presence of this blob *first*. If present, it simply grabs all table blobs from fw_cfg and assembles them (e.g. via get_external()). Create its own type 0 if not already included in fw_cfg, and recompute the checksum for the entry point.
If the entry point blob is not found, smbios_setup() proceeds with its current logic (looking for table or field blobs in fw_cfg, and creating its own entry point structure).
Now, 2 would be uglier, hands down, but has the advantage of not adding arbitrary restrictions on what the type0 structure can look like.
If we go with 1 (all I need is you all to say "go for it, we're OK with arbitrary restrictions on type0" :) ), I'll add prominent comments in the qemu smbios source about what the restrictions are.
We have vendor, version, and date, currently. Date can be "YYYY-MM-DD" or somesuch (for a total strlen of 10, not including \0).
Any idea what the longest "vendor" and "version" string might look like ?
What do we do if we have *shorter* strings than that, fill with spaces to keep the hardcoded strlen intact across the qemu/bios demarc ?
Thanks, --Gabriel