From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WV6Tp-0008JV-Vi for qemu-devel@nongnu.org; Tue, 01 Apr 2014 17:44:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WV6Tj-0000P5-Ot for qemu-devel@nongnu.org; Tue, 01 Apr 2014 17:44:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WV6Tj-0000Ox-GP for qemu-devel@nongnu.org; Tue, 01 Apr 2014 17:44:19 -0400 Message-ID: <533B332C.7090701@redhat.com> Date: Tue, 01 Apr 2014 23:44:12 +0200 From: Laszlo Ersek MIME-Version: 1.0 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> <20140401212808.GI9466@ERROL.INI.CMU.EDU> In-Reply-To: <20140401212808.GI9466@ERROL.INI.CMU.EDU> Content-Type: text/plain; charset=ISO-8859-1 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: "Gabriel L. Somlo" , Kevin O'Connor Cc: agraf@suse.de, seabios@seabios.org, qemu-devel@nongnu.org, armbru@redhat.com, alex.williamson@redhat.com, kraxel@redhat.com, imammedo@redhat.com On 04/01/14 23:28, Gabriel L. Somlo wrote: > On Tue, Apr 01, 2014 at 04:28:32PM -0400, Kevin O'Connor wrote: >>> 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) >>> >>> - 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). >> >> 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. The only thing that has been raised as an issue with this >> is one bit in the smbios table (UEFI support). For this one bit, I >> think QEMU can just put together a sane default and the firmware can >> patch up the one bit (either manually or via a new romfile_loader >> command). >> >>> >>> - this means the smbios structure header has to be left >>> up to the BIOS >>> >>> - the BIOS is then responsible for setting the smbios >>> spec version (2.4 for SeaBIOS, 2.7.1 for OVMF). >>> >>> On that last point, at least Linux seems to be OK with individual >>> type tables having a higher version than the structure header; i.e., >>> dmidecode works fine when e.g. the structure header says 2.4 but >>> the type 4 cpu record is 2.6. I'll test on Windows and OS X as well, >>> and post my results here. >>> >>> My one remaining question is: how do we get the BIOS to *not* generate >>> a certain table type that's being left out on purpose by QEMU ? >>> >>> I'm talking here of type 20, which is no longer required as of spec >>> v2.5, and which would unnecessarily complicate things if/when more >>> than two E820_RAM memory areas are present... >> >> The above are good examples why I think QEMU should be the sole owner >> of the SMBIOS. > > Assuming all relevant QEMU maintainers are OK with the idea of > creating a full SMBIOS blob (with e.g. type 0 defaulting to the > relevant SeaBIOS values, override-able to fit some different bios, > e.g. OVMF), would you take a patch to check for this blob in > smbios_setup() (in SeaBIOS src/fw/smbios.c) ? Right now, it's either > individual fields or table-at-a-time blobs only, AFAICT. > > Assuming "yes", would OVMF accept a similar patch (unless it's already > set up to receive such a blob, I forget whether that came up earlier > in the thread) ? 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). If qemu gives OVMF a complete, concatenated dump of all tables, I'll have to split that up into individual tables, and install those one by one. qemu --[fw_cfg]--> OVMF platform code --[EFI_SMBIOS_PROTOCOL]--> edk2 "some" format: strictly per-table - field patch - per-table blob - complete dump? I think that concatenating table-at-a-time blobs in SeaBIOS is easier than parsing & splitting a complete dump into tables in OVMF. Kevin might disagree of course :) Thanks Laszlo