From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXAsB-0006lJ-Gc for qemu-devel@nongnu.org; Mon, 07 Apr 2014 10:50:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WXAs2-0003Nb-Dj for qemu-devel@nongnu.org; Mon, 07 Apr 2014 10:50:07 -0400 Received: from mail-qg0-x22e.google.com ([2607:f8b0:400d:c04::22e]:60640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXAs2-0003NV-7H for qemu-devel@nongnu.org; Mon, 07 Apr 2014 10:49:58 -0400 Received: by mail-qg0-f46.google.com with SMTP id j107so1492619qga.19 for ; Mon, 07 Apr 2014 07:49:57 -0700 (PDT) Date: Mon, 7 Apr 2014 10:49:54 -0400 From: "Gabriel L. Somlo" Message-ID: <20140407144953.GG1602@ERROL.INI.CMU.EDU> References: <20140401143902.GA6462@morn.localdomain> <533ADF7D.6010804@redhat.com> <20140401184726.GH9466@ERROL.INI.CMU.EDU> <20140401202832.GA24065@morn.localdomain> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140407141435.GA22185@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 10:14:36AM -0400, Kevin O'Connor wrote: > How about having QEMU produce the smbios table with a dummy type0 > table and then both seabios and ovmf can replace the type0 table if > desired. After all, if OVMF is splitting the blob into tables, it can > just as easily replace type0 as append it. > > This way, the QEMU output is technically complete. And if someone > wishes to code up SeaBIOS to do the type0 replace (I'm not convinced > it's even necessary) then at least that SeaBIOS code could be used on > coreboot as well. OK, so as far as I'm concerned, it's down to two alternatives: 1. I create a full blob, starting with the anchor/entrypoint, and followed by a (dummy) type 0, type 1, etc, etc. all the way to the type 127 end marker. Pass that in via fw_cfg, and each BIOS is then responsible for editing type 0, overwriting it with appropriate values. I like this very much :) except for a serious discomfort with the idea of imposing an additional "convention" on the size (and choice of) strings included with the type0 table, beyond the smbios spec. 2. I create a third fw_cfg smbios "type" for the entry point structure. The BIOS (e.g. smbios_setup() in SeaBIOS) checks for the presence of this blob *first*. If present, it simply grabs all table blobs from fw_cfg and assembles them (e.g. via get_external()). Create its own type 0 if not already included in fw_cfg, and recompute the checksum for the entry point. If the entry point blob is not found, smbios_setup() proceeds with its current logic (looking for table or field blobs in fw_cfg, and creating its own entry point structure). Now, 2 would be uglier, hands down, but has the advantage of not adding arbitrary restrictions on what the type0 structure can look like. If we go with 1 (all I need is you all to say "go for it, we're OK with arbitrary restrictions on type0" :) ), I'll add prominent comments in the qemu smbios source about what the restrictions are. We have vendor, version, and date, currently. Date can be "YYYY-MM-DD" or somesuch (for a total strlen of 10, not including \0). Any idea what the longest "vendor" and "version" string might look like ? What do we do if we have *shorter* strings than that, fill with spaces to keep the hardcoded strlen intact across the qemu/bios demarc ? Thanks, --Gabriel