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

[Kevin O'Connor <kevin@koconnor.net>]

On Tue, Apr 01, 2014 at 02:47:27PM -0400, Gabriel L. Somlo wrote:
> On Tue, Apr 01, 2014 at 05:47:09PM +0200, Laszlo Ersek wrote:
> > bit 2 of the BIOS Characteristics Extension Byte 2 (7.1.2.2) is set, for
> > "Enable Targeted Content Distribution".
> > 
> > In OVMF, the same byte has the following bits set:
> > 
> > Bit 3 -- UEFI Specification is supported.
> > Bit 4 -- The SMBIOS table describes a virtual machine. (If this bit is
> >          not set, no inference can be made about the virtuality of the
> >          system.)
> > 
> > I have nothing against bit 2 (I didn't include it because I had no clue
> > what it meant, but we can certainly set that bit down the road). Bit 3
> > would be wrong for SeaBIOS, and it would be wrong to leave clear for
> > OVMF. Bit 4 would be wrong for SeaBIOS (as a static default), but is
> > correct (and very nice, although not necessary) for OVMF.
> 
> I can add an extra command line option for type 0 defaults (e.g.
> "char_ext" but we can pick a better name):
> 
>     "-smbios type=0,vendor='foo',version='x.y',char_ext=4"
> 
> ... and make the user responsible for supplying the correct value
> if/when they wish to override the defaults. I'll do that in the
> v5 patch set I'm working on right now :)
> 
> As an aside, I think in the end it doesn't matter much if we supply
> individual field defaults or full tables for *optional* types such
> as type 0. I just like to generate full tables across the board to
> keep reusing the same code, rather than leave the individual-field
> logic in just for this one table type...
> 
> 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.

-Kevin