Hi, > > 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. 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 ... cheers, Gerd