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

Kevin O'Connor kevin at koconnor.net
Mon Apr 7 17:23:44 CEST 2014

On Mon, Apr 07, 2014 at 10:49:54AM -0400, Gabriel L. Somlo wrote:
> 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.

I agree that was too ugly.  What I'm proposing now is that QEMU
produce a valid type0 table (with strings populated, but no special
padding) along with all the other tables (up to and including type

Then SeaBIOS and OVMF can either pass this on exactly as is, or they
can modify the table to replace type0.

This is a few more lines of code for SeaBIOS (to replace type0 instead
of just patching it), but it has the advantage that QEMU developers
know they must produce a valid smbios table according to the specs and
the firmware developers know they will get a valid smbios table
(according to the specs) and know they must ultimately produce a valid
smbios table.

So, I'm suggesting QEMU produce two new fw_cfg files: an anchor file
with the valid anchor table (the address pointer can be just set to
zero), and an smbios table file with the complete set of smbios tables
formatted according to the smbios spec.  SeaBIOS can then use the
existence of one of these new files to determine if it should deploy
(and optionally modify) them or if it should use the old smbios
generation code.


More information about the SeaBIOS mailing list