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