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

[Laszlo Ersek]

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):

VOLUME 5: Platform Initialization Specification
Standards
6 SMBIOS Protocol

The function to call is EFI_SMBIOS_PROTOCOL.Add().

>> 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... :)

Thanks
Laszlo