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

[Gabriel L. Somlo]

On Tue, Apr 01, 2014 at 04:28:32PM -0400, Kevin O'Connor wrote:
> > From the conversation so far, it seems to me that:
> > 
> > 	- type 0 is best left to the BIOS (user overrides via
> > 	  command line at their own risk)
> > 
> > 	- therefore, the maximum granularity of QEMU-generated
> > 	  elements should be full tables of a given type, and
> > 	  not the full SMBIOS blob at once (other mechanisms to
> > 	  allow the BIOS to insert its own type 0 welcome, but
> > 	  so far this seems the most straightforward one).
> 
> I don't agree - I think ultimately we want QEMU to generate the full
> SMBIOS table and pass it to the firmware via the romfile_loader
> mechanism.  The only thing that has been raised as an issue with this
> is one bit in the smbios table (UEFI support).  For this one bit, I
> think QEMU can just put together a sane default and the firmware can
> patch up the one bit (either manually or via a new romfile_loader
> command).
> 
> > 
> > 	- this means the smbios structure header has to be left
> > 	  up to the BIOS
> > 
> > 	- the BIOS is then responsible for setting the smbios
> > 	  spec version (2.4 for SeaBIOS, 2.7.1 for OVMF).
> > 
> > On that last point, at least Linux seems to be OK with individual
> > type tables having a higher version than the structure header; i.e.,
> > dmidecode works fine when e.g. the structure header says 2.4 but
> > the type 4 cpu record is 2.6. I'll test on Windows and OS X as well,
> > and post my results here.
> > 
> > My one remaining question is: how do we get the BIOS to *not* generate
> > a certain table type that's being left out on purpose by QEMU ?
> > 
> > I'm talking here of type 20, which is no longer required as of spec
> > v2.5, and which would unnecessarily complicate things if/when more
> > than two E820_RAM memory areas are present...
> 
> The above are good examples why I think QEMU should be the sole owner
> of the SMBIOS.

Assuming all relevant QEMU maintainers are OK with the idea of
creating a full SMBIOS blob (with e.g. type 0 defaulting to the
relevant SeaBIOS values, override-able to fit some different bios,
e.g. OVMF), would you take a patch to check for this blob in
smbios_setup() (in SeaBIOS src/fw/smbios.c) ? Right now, it's either
individual fields or table-at-a-time blobs only, AFAICT.

Assuming "yes", would OVMF accept a similar patch (unless it's already
set up to receive such a blob, I forget whether that came up earlier
in the thread) ?

Thanks,
  Gabriel

--
In Soviet Russia, problem divide-and-conquer YOU ;)