On 04/07/14 16:14, Kevin O'Connor wrote:
On Mon, Apr 07, 2014 at 09:09:56AM +0200, Gerd Hoffmann wrote:
The only fly in this ointment may be that type 0 doesn't have a fixed length that could be edited in place, if you consider the various strings that get tacked on to the end of it. So you'd still have to slide the rest of the smbios payload left or right to shrink or enlarge the type 0 blob, depending on how you modify the various strings it contains...
The dummy type 0 subtable that QEMU generates can have dummy space padded strings that the firmware can overwrite. Until recently, the max size smbios string was 64 bytes, so that size could be used. (As above, I admit that this is ugly, but the alternatives also seem ugly.) Another option would be to just leave the strings at a QEMU default as that's no different from what SeaBIOS does today.
I don't think we need to make it that complicated. smbios tables don't have any references, right? I mean any references which would need a fixup (such as table pointers in RSDP in acpi) and therefore would need the romfile_loader. The string references within a table are relative don't need special care.
The smbios anchor table needs to have the address of the main smbios table. It would be preferable to get the anchor table from qemu as the anchor table has the smbios version info.
But, anchor table aside, you are correct.
Gabriel has code to generate all tables needed in qemu meanwhile, so I think we can simply have a blob in fw_cfg with all tables (except type0). firmware generates type0 table like it does today, then simply appends the fw_cfg blob as-is, then appends a end-of-tables marker. Done.
OVMF probably would have to parse the blob, split it into tables, then install them one by one. But I suspect that will be less code than dealing with the complex smbios fw_cfg interface we have today ...
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.
Works for me.
Thanks Laszlo