[SeaBIOS] [QEMU v6 PATCH 00/17] SMBIOS: build full tables in QEMU

Gabriel L. Somlo gsomlo at gmail.com
Wed Apr 16 23:02:21 CEST 2014

OK, so I have the "legacy" (field-by-field, types 0 and 1 only) code
back in, right next to the new aggregate-smbios-table-plus-entrypoint
code, tested and apparently working fine.

Before I get carried away with "git rebase", do we still want to go
through the whole patch sequence of generating aggregate tables
identical to what SeaBIOS would have (including e.g. type 20), then
drop type 20 and upgrade to smbios spec v2.8, etc ?

Since we're keeping the legacy code, I can add in the new code (only
for machine types >= 2.1) directly as smbios spec v2.8 compliant
(mainly without adding in generation for type 20, then ripping it
right back out again).

This would result in a smaller, cleaner patch set. Any objections ?

On Wed, Apr 16, 2014 at 08:41:51AM +0200, Gerd Hoffmann wrote:
> Global variable, simliar to smbios_type1_defaults.  machine type init
> code will set it accordingly.  smbios code just does "if
> (smbios_generate_tables) { ... }" (or however we name this).

OK, so right now I'm parsing the "version" argument to what is
currently smbios_set_type1_defaults() (and will become
smbios_set_defaults() after patching).

This gets passed in by pc_piix.c or pc_q35.c from args->machine->name,
and comes in turn from the various machine definitions in

I noticed some of the older QEMUMachine structures have a hw_version
member set, but the latest I could find being set explicitly is 1.0,
and only in pc_piix.c.

On current (2.0) piix and q35 machines, the hw_version field is NULL,
is that a bug or a feature ?

If the latter (feature), is there a better way to find out which side
of "2.1" I'm currently on than by scraping it out of args->machine->name ?


More information about the SeaBIOS mailing list