From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVMj6-0003Ta-Kj for qemu-devel@nongnu.org; Wed, 02 Apr 2014 11:05:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVMiy-0003IX-JO for qemu-devel@nongnu.org; Wed, 02 Apr 2014 11:05:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVMiy-0003IL-B2 for qemu-devel@nongnu.org; Wed, 02 Apr 2014 11:05:08 -0400 Message-ID: <1396451097.31715.20.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Wed, 02 Apr 2014 17:04:57 +0200 In-Reply-To: <20140401202832.GA24065@morn.localdomain> References: <1395185009-26532-1-git-send-email-somlo@cmu.edu> <20140326195849.GD1543@ERROL.INI.CMU.EDU> <20140326223610.GA28587@morn.localdomain> <20140331201807.GG9466@ERROL.INI.CMU.EDU> <533A7B60.7080408@redhat.com> <20140401143902.GA6462@morn.localdomain> <533ADF7D.6010804@redhat.com> <20140401184726.GH9466@ERROL.INI.CMU.EDU> <20140401202832.GA24065@morn.localdomain> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: agraf@suse.de, alex.williamson@redhat.com, seabios@seabios.org, qemu-devel@nongnu.org, armbru@redhat.com, "Gabriel L. Somlo" , imammedo@redhat.com, Laszlo Ersek Hi, > > From the conversation so far, it seems to me that: > > > > - type 0 is best left to the BIOS (user overrides via > > command line at their own risk) I think it was a bad idea to allow overriding type0 fields in the first place. It also isn't used in practice. I don't think it is a big problem to loose that capability. > > - therefore, the maximum granularity of QEMU-generated > > elements should be full tables of a given type, and > > not the full SMBIOS blob at once (other mechanisms to > > allow the BIOS to insert its own type 0 welcome, but > > so far this seems the most straightforward one). Just an idea: Is the table ordering important? I don't think so. If qemu supplies a blob with all tables except type0, can the firmware simply append a type0 record to the blob supplied by qemu? > I don't agree - I think ultimately we want QEMU to generate the full > SMBIOS table and pass it to the firmware via the romfile_loader > mechanism. I still think the firmware (and *only* the firmware) should supply the type0 table. I also think seabios should fill in something more sensible in there, such as "Vendor: SeaBIOS" and "Version: rel-1.7.4-0-g96917a8-...". > The only thing that has been raised as an issue with this > is one bit in the smbios table (UEFI support). IMO 'dmidecode -t0' should show what firmware you are running (seabios/ovmf/coreboot/whatever), not something made up by qemu. cheers, Gerd