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

[Gabriel L. Somlo]

On Mon, Apr 07, 2014 at 10:14:36AM -0400, Kevin O'Connor wrote:
> 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.

OK, so as far as I'm concerned, it's down to two alternatives:

1. I create a full blob, starting with the anchor/entrypoint, and
followed by a (dummy) type 0, type 1, etc, etc. all the way to
the type 127 end marker. Pass that in via fw_cfg, and each BIOS
is then responsible for editing type 0, overwriting it with
appropriate values.

I like this very much :) except for a serious discomfort with the idea
of imposing an additional "convention" on the size (and choice of)
strings included with the type0 table, beyond the smbios spec.


2. I create a third fw_cfg smbios "type" for the entry point
structure.

The BIOS (e.g. smbios_setup() in SeaBIOS) checks for the presence of
this blob *first*. If present, it simply grabs all table blobs from
fw_cfg and assembles them (e.g. via get_external()). Create its own
type 0 if not already included in fw_cfg, and recompute the checksum for
the entry point.

If the entry point blob is not found, smbios_setup() proceeds with its
current logic (looking for table or field blobs in fw_cfg, and
creating its own entry point structure).


Now, 2 would be uglier, hands down, but has the advantage of not
adding arbitrary restrictions on what the type0 structure can look
like.



If we go with 1 (all I need is you all to say "go for it, we're OK
with arbitrary restrictions on type0" :) ), I'll add prominent
comments in the qemu smbios source about what the restrictions are.

We have vendor, version, and date, currently. Date can be "YYYY-MM-DD"
or somesuch (for a total strlen of 10, not including \0).

Any idea what the longest "vendor" and "version" string might look
like ?

What do we do if we have *shorter* strings than that, fill with
spaces to keep the hardcoded strlen intact across the qemu/bios
demarc ?


Thanks,
--Gabriel