From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXWR7-0002d4-Dj for qemu-devel@nongnu.org; Tue, 08 Apr 2014 09:51:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WXWQy-0007zu-8W for qemu-devel@nongnu.org; Tue, 08 Apr 2014 09:51:37 -0400 Received: from mail-qc0-x234.google.com ([2607:f8b0:400d:c01::234]:38417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXWQy-0007zo-2w for qemu-devel@nongnu.org; Tue, 08 Apr 2014 09:51:28 -0400 Received: by mail-qc0-f180.google.com with SMTP id w7so955633qcr.39 for ; Tue, 08 Apr 2014 06:51:27 -0700 (PDT) Date: Tue, 8 Apr 2014 09:51:25 -0400 From: "Gabriel L. Somlo" Message-ID: <20140408135124.GN1602@ERROL.INI.CMU.EDU> References: <1396451097.31715.20.camel@nilsson.home.kraxel.org> <20140405003410.GA13086@morn.localdomain> <20140405011513.GB31429@foober.ini.cmu.edu> <20140405022632.GA21769@morn.localdomain> <1396854596.5001.17.camel@nilsson.home.kraxel.org> <20140407141435.GA22185@morn.localdomain> <20140407144953.GG1602@ERROL.INI.CMU.EDU> <20140407152344.GA26674@morn.localdomain> <20140407180520.GI1602@ERROL.INI.CMU.EDU> <20140407185708.GA10352@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140407185708.GA10352@morn.localdomain> 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: seabios@seabios.org, Laszlo Ersek , Gerd Hoffmann , qemu-devel@nongnu.org On Mon, Apr 07, 2014 at 02:57:08PM -0400, Kevin O'Connor wrote: > On Mon, Apr 07, 2014 at 02:05:21PM -0400, Gabriel L. Somlo wrote: > > On Mon, Apr 07, 2014 at 11:23:44AM -0400, Kevin O'Connor wrote: > > > So, I'm suggesting QEMU produce two new fw_cfg files: an anchor file > > > with the valid anchor table (the address pointer can be just set to > > > zero), and an smbios table file with the complete set of smbios tables > > > formatted according to the smbios spec. SeaBIOS can then use the > > > existence of one of these new files to determine if it should deploy > > > (and optionally modify) them or if it should use the old smbios > > > generation code. > > > > Oh, OK. Right now we have (in qemu): > > > > #define SMBIOS_FIELD_ENTRY 0 > > #define SMBIOS_TABLE_ENTRY 1 > > > > I will be adding (actually, migrating to): > > > > #define SMBIOS_ANCHOR_ENTRY 2 /* for the smbios entry point table */ > > #define SMBIOS_FULLTABLE_ENTRY 3 /* for the blob containing all types */ > > No - don't do that. Lets leave the existing smbios fw_cfg entry > (0x8001) unchanged. Instead, introduce two new fw_cfg files using the > fw_cfg_add_file() interface (eg, "etc/smbios/smbios-anchor" and > "etc/smbios/smbios-tables"). OK. > > I can add such a structure for the anchor/entrypoint table and for the > > full blob-of-tables payload, in which I can tell you how big type 0 is, > > so the BIOS (SeaBIOS/TianoCore) side surgery can be made that much > > easier... > > It's trivial for the firmware to calculate this on its own, so I > recommend just putting the anchor table and main tables unmodified in > their respective fw_cfg files. Not sure why it never occurred to me before (lack of caffeine, or various day-job related distractions :) ) but if the QEMU default dummy type 0 table is just that -- a dummy table -- there's *nothing* preventing me from leaving all (three) of its strings *empty* :) Then we'll know *exactly* what the size of type 0 is, when it's time to surgically transplant a new one within the BIOS... I remember neither Windows, Linux (F20 live) or OS X objecting to a type 0 smbios table with all-undefined strings, during some previous tests. I'll try to send out an updated patch set later in the week. Thanks again, --Gabriel