From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNkoG-0007ia-JR for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:43:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNkoF-0007hw-Qg for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:43:56 -0400 Received: from [199.232.76.173] (port=36877 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNkoF-0007hj-CL for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:43:55 -0400 Received: from mx1.redhat.com ([66.187.233.31]:35487) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNkoF-0005Wa-57 for qemu-devel@nongnu.org; Tue, 29 Jul 2008 04:43:55 -0400 Message-ID: <488ED7F0.5050205@redhat.com> Date: Tue, 29 Jul 2008 10:42:24 +0200 From: Chris Lalancette MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/3]: Add UUID command-line option References: <488DC8B2.1070009@redhat.com> <20080728141515.GJ3196@minantech.com> <488DD98D.5010907@codemonkey.ws> <20080729081525.GI32498@redhat.com> In-Reply-To: <20080729081525.GI32498@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Gleb Natapov , qemu-devel@nongnu.org Daniel P. Berrange wrote: > I'd really welcome addition of SMBIOS support too - for x86 the UUID > in the SMBIOS tables, is the most effective way for a guest admin to > find their machine identify in a format that can be correlated with > the host machine by external admin tools. Xen has code for doing SMBIOS > tables that could be useful to anyone wanting to work on this. Though it > won't be a straight port since they integrate it with the HVM loader > firmware, the general data table setup code ought to be reusable, only > leaving the BIOS integration part. Again, just to be clear; SMBIOS support is already there today in Bochs BIOS (you can see this by doing "dmidecode" inside a guest). The only real thing this patchset was changing was plumbing it through to get the UUID from the Qemu device model through the VMware back door. Since there seems to be aversion to the VMware back door, however, the only real question is how we pass UUID information from the Qemu device model through to the Boch BIOS, so it can place the UUID in the SMBIOS tables that it is already building. Suggestions so far have been: 1) Patch the UUID directly into the Bochs BIOS when the Qemu process is loading it. This is pretty straightforward, but not very extensible. 2) Find or come up with a "standard" backdoor mechanism. I would think this would be quite similar to the VMware one, but wouldn't be subject to VMware's whims on it. Chris Lalancette