From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrHIN-0007Kw-72 for qemu-devel@nongnu.org; Tue, 07 Apr 2009 15:49:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrHII-0007Ki-MW for qemu-devel@nongnu.org; Tue, 07 Apr 2009 15:49:18 -0400 Received: from [199.232.76.173] (port=58356 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrHII-0007Kf-HW for qemu-devel@nongnu.org; Tue, 07 Apr 2009 15:49:14 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:41345) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LrHIH-00025t-W6 for qemu-devel@nongnu.org; Tue, 07 Apr 2009 15:49:14 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n37Jk0Uw026985 for ; Tue, 7 Apr 2009 15:46:00 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n37JnCTv183950 for ; Tue, 7 Apr 2009 15:49:12 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n37JnCaV019620 for ; Tue, 7 Apr 2009 15:49:12 -0400 Message-ID: <49DBAE36.5040401@us.ibm.com> Date: Tue, 07 Apr 2009 14:49:10 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1237835133.7276.1107.camel@lappy> <1237835465.15558.4.camel@lappy> <49DA5CEA.7040209@us.ibm.com> <1239057273.4726.76.camel@lappy> <49DA854B.4000905@us.ibm.com> <1239132849.6184.131.camel@bling> In-Reply-To: <1239132849.6184.131.camel@bling> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [kvm] Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: qemu-devel , kvm Alex Williamson wrote: > On Mon, 2009-04-06 at 17:42 -0500, Anthony Liguori wrote: > > That helps, but we have the same complexity in getting the data into the > the bios. Adding a new QEMU_CFG_* for each field in every table we want > to specify seems excessive. Right. > I'm half tempted to generate all the smbios > entries in qemu and push them through a port to the bios. That would > leave a lot of duplicate code in bochs though. Maybe the bios could > read a stream of these through the port: > > uint16_t length; > uint8_t type; /* 0: field, 1: table */ > union { > struct { > uint8_t type; /* smbios entry type */ > uint8_t offset; > uint8_t data[]; > } field; > struct { > uint8_t data[]; /* binary blob */ > } table; > } entry; > > We could convert uuid to use this too. Yes, this is what I was leaning toward too. > The bios doesn't have a very > effective means to seek through these, but maybe its not an issue as > long as these entries are sparsely used. We could also use the table > generation to enforce mutual exclusion between specifying fields and > tables to avoid the uuid issue in the previous set. Other ideas? > I'm pretty happy with this. The argument against it is that if we pass higher level information down via the FW interface, other types of FW (like OpenBIOS) could also use that information in a meaningful way. The problem is, beyond things like UUID, you start to get into pretty specific stuff and I'm not convinced it would all generalize very well. OEM tables are also impossible to represent this way. So yeah, plumbing the tables directly through to the BIOS seems to make sense to me. > Thanks, > > Alex > > > -- Regards, Anthony Liguori