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
