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

[Laszlo Ersek <lersek@redhat.com>]

On 04/02/14 14:38, Gabriel L. Somlo wrote:
> 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):
>>
>> 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... :)
> 
> Kevin, Laszlo,
> 
> What if I found a way to send an entry point structure via fw_cfg, as
> a signal to ${BIOS} to simply assemble all the table-at-a-time blobs,
> but without generating any of its own ?
> 
> I'm still working my way through whether *I* like the idea or not, but
> figured I'd throw it out there as a potential compromise ? :)

If you send the entry point structure in a new fw_cfg file, then (I
believe) I could ignore it easily, and just go ahead with the
table-at-a-time blobs. OVMF has defaults (fallbacks) only for Type 0 and
Type 1 tables now, which you are (almost) guaranteed to send down
anyway, so the above approach might work for OVMF without even changing
the OVMF code. (Regarding individual fields, you'd simply not send such,
if I understand correctly.)

Thanks
Laszlo