Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)

[Gerd Hoffmann <kraxel@redhat.com>]

  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