qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
Date: Wed, 2 Apr 2014 08:38:18 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]