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

[Laszlo Ersek]

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