From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrH3v-00005H-GG for qemu-devel@nongnu.org; Tue, 07 Apr 2009 15:34:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrH3q-0008S8-RD for qemu-devel@nongnu.org; Tue, 07 Apr 2009 15:34:22 -0400 Received: from [199.232.76.173] (port=56519 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrH3q-0008S5-Id for qemu-devel@nongnu.org; Tue, 07 Apr 2009 15:34:18 -0400 Received: from g4t0014.houston.hp.com ([15.201.24.17]:40631) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LrH3q-0005yw-4x for qemu-devel@nongnu.org; Tue, 07 Apr 2009 15:34:18 -0400 From: Alex Williamson In-Reply-To: <49DA854B.4000905@us.ibm.com> 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> Content-Type: text/plain Date: Tue, 07 Apr 2009 13:34:09 -0600 Message-Id: <1239132849.6184.131.camel@bling> Mime-Version: 1.0 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: Anthony Liguori Cc: qemu-devel , kvm On Mon, 2009-04-06 at 17:42 -0500, Anthony Liguori wrote: > Alex Williamson wrote: > > Hi Anthony, > > > > On Mon, 2009-04-06 at 14:50 -0500, Anthony Liguori wrote: > > > >> Alex Williamson wrote: > >> > >> I know we have to support blobs because of OEM specific smbios entries, > >> but there are a number of common ones that it would probably be good to > >> specify in a less user-unfriendly way. What do you think? > >> > > > > Yeah, I'll admit this is a pretty unfriendly interface. I get from your > > comment on the other part of the patch that you'd prefer not to get into > > the mess of having both binary blobs and command line switches > > augmenting the blobs. This seems reasonable, but also means that we > > need a way to fully define the tables we generate from the command line. > > For a type 0 entry, that might mean the following set of switches: > > > > -bios-version, -bios-date, -bios-characteristics, -bios-release > > > > You could go one level higher: > > -smbios type=0,bios-version='1.0',bios-date='2009/10/20' etc. 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. 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. 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? Thanks, Alex