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

[Kevin O'Connor]

On Wed, Apr 02, 2014 at 12:35:26AM +0200, Laszlo Ersek wrote:
> On 04/02/14 00:00, Kevin O'Connor wrote:
> > On Tue, Apr 01, 2014 at 11:44:12PM +0200, Laszlo Ersek wrote:
> >> Right now, OVMF can accept individual fields, or table-at-a-time blobs,
> >> via fw_cfg.
> >>
> >> The internal interface (EFI_SMBIOS_PROTOCOL) expects one table at a time
> >> (for which table-at-a-time blobs are a perfect match).
> > 
> > I wasn't aware of this.  The SMBIOS spec calls for all the sub-tables
> > to be concatenanted into a single linear area of memory.  Is there
> > something in EFI or OVMF that is dictating otherwise?  Can you provide
> > a link so I can further understand?  (I briefly checked through the
> > UEFI v2.3.1 spec and nothing popped out at me.)
> 
> The "UEFI Specification" is not relevant here, the "UEFI Platform
> Initialization (PI) Specification" is.
> 
> You can download the PI spec at <http://www.uefi.org/specs/access>. The
> relevant section is (I have version 1.2.1):

Oh, those crazy UEFI guys!

The internal edk2 code appears to use these individual calls to
ultimately build the concatenated smbios table from them.  So, nothing
special here - just standard UEFI over-design.

> >> I think that concatenating table-at-a-time blobs in SeaBIOS is easier
> >> than parsing & splitting a complete dump into tables in OVMF.
> > 
> > I don't think it's very difficult either way.  It would be nice,
> > though, if there was just one owner for the smbios.  The current setup
> > where some data comes from QEMU and some from the firmware, along with
> > mechanisms for providing defaults and overrides is way too complex in
> > my opinion.
> 
> I certainly agree with the direction. I'm OK with the current
> table-at-a-time blobs (which should leave only the SMBIOS entry point to
> the firmware). I'm also OK with any new, comprehensive format that
> allows me, with reasonable parsing, to identify the individual tables in
> the big concat (and to throw away the passed down entry point).
> 
> I already wrote display_uuid() [src/fw/smbios.c] for SeaBIOS, so I guess
> I could repeat the exercise if it's unavoidable... :)

Makes sense.

Thanks.
-Kevin