[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in
From: |
Kevin O'Connor |
Subject: |
Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU) |
Date: |
Tue, 1 Apr 2014 16:28:32 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Kevin O'Connor, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU),
Kevin O'Connor <=
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Kevin O'Connor, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/01
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Laszlo Ersek, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Kevin O'Connor, 2014/04/04
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gerd Hoffmann, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/02
- Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU), Gabriel L. Somlo, 2014/04/02