From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUiey-0002y2-SF for qemu-devel@nongnu.org; Mon, 31 Mar 2014 16:18:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WUiep-0006DT-Pu for qemu-devel@nongnu.org; Mon, 31 Mar 2014 16:18:20 -0400 Received: from mail-qc0-x232.google.com ([2607:f8b0:400d:c01::232]:41086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUiep-0006DM-Ls for qemu-devel@nongnu.org; Mon, 31 Mar 2014 16:18:11 -0400 Received: by mail-qc0-f178.google.com with SMTP id i8so9436356qcq.23 for ; Mon, 31 Mar 2014 13:18:10 -0700 (PDT) Date: Mon, 31 Mar 2014 16:18:08 -0400 From: "Gabriel L. Somlo" Message-ID: <20140331201807.GG9466@ERROL.INI.CMU.EDU> References: <1395185009-26532-1-git-send-email-somlo@cmu.edu> <20140326195849.GD1543@ERROL.INI.CMU.EDU> <20140326223610.GA28587@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140326223610.GA28587@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: armbru@redhat.com, seabios@seabios.org, agraf@suse.de, qemu-devel@nongnu.org, alex.williamson@redhat.com, kraxel@redhat.com, imammedo@redhat.com, lersek@redhat.com On Wed, Mar 26, 2014 at 06:36:10PM -0400, Kevin O'Connor wrote: > On Wed, Mar 26, 2014 at 03:58:50PM -0400, Gabriel L. Somlo wrote: > > - SeaBIOS is still in charge of providing the smbios_entry_point > > structure, and it's unlikely we can reasonably expect it to > > bump the version to 2.5 (not that it seems to matter, if my > > tests are to be believed) > > This is why ultimately we want to use the romfile_loader mechanism for > smbios - that interface will allow qemu to generate both the smbios > table and the smbios entry point. Ah, so romfile_loader is the "whole-blob" fw_cfg transfer method (so far in smbios.c we've been dealing with individual fields, and individual table types). The only sticking point remaining would be who gets to generate the Type 0 (BIOS Information) table and when, which is something QEMU should arguably NOT be doing on behalf of SeaBIOS (or OVMF, or ...). I guess everyone's busy with QEMU 2.0, so I'll keep playing with this stuff on my own and bring it up again afterwards. Obviously, more comments and feedback are welcome at any time, should there be any interest :) Thanks, --Gabriel