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

[Kevin O'Connor]

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.

-Kevin