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 ? :) Thx, --Gabriel