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