From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WG3wR-00028o-7N for qemu-devel@nongnu.org; Wed, 19 Feb 2014 04:59:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WG3wL-0001Eh-9Y for qemu-devel@nongnu.org; Wed, 19 Feb 2014 04:59:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:4203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WG3wL-0001EJ-15 for qemu-devel@nongnu.org; Wed, 19 Feb 2014 04:59:41 -0500 Message-ID: <1392803974.20987.13.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Wed, 19 Feb 2014 10:59:34 +0100 In-Reply-To: <20140218191728.GS29329@ERROL.INI.CMU.EDU> References: <20140217160947.GO29329@ERROL.INI.CMU.EDU> <20140217203333.GB30268@morn.localdomain> <1392718893.4724.12.camel@nilsson.home.kraxel.org> <20140218191728.GS29329@ERROL.INI.CMU.EDU> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2, Ping] SMBIOS: Upgrade Type17 to v2.3, add Type2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: pbonzini@redhat.com, Kevin O'Connor , seabios@seabios.org, qemu-devel@nongnu.org, agraf@suse.de Hi, > However, when I compare unmodified SMBIOS against what I get when > supplying the patched binary table via command line, I get this: As Laszlo already sayed: one table per file. > > If seabios finds a table provided by qemu it used it, otherwise it > > (possibly) generates its own. So we can smoothly switch over to qemu, > > table-by-table. You can have qemu provide type2+type17 tables, and > > leave everything else as-is. And when doing it in qemu it is easy to do > > it for new machine types only. > > I could try to hack at the QEMU smbios source file to try to find > where the problem lies (at least why handover to SeaBIOS doesn't work > as expected), but I'm not sure providing command line flags for > inputting each record type individually is a scalable way to move > forward. Agree. qemu should simply autogenerate the entries (where it can). i.e. basically port seabios smbios_init_type_17 function to qemu, then hook the result into the smbios_entries array. The code to do that is in smbios_entry_add(). You probably want to factor that out ino a small helper function which is then called by both smbios_entry_add() and the type17 init function. cheers, Gerd