From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNWip-00007H-67 for qemu-devel@nongnu.org; Mon, 28 Jul 2008 13:41:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNWim-00005i-Ep for qemu-devel@nongnu.org; Mon, 28 Jul 2008 13:41:22 -0400 Received: from [199.232.76.173] (port=35388 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNWim-00005e-4Q for qemu-devel@nongnu.org; Mon, 28 Jul 2008 13:41:20 -0400 Received: from yw-out-1718.google.com ([74.125.46.154]:32472) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNWij-0003pH-QG for qemu-devel@nongnu.org; Mon, 28 Jul 2008 13:41:20 -0400 Received: by yw-out-1718.google.com with SMTP id 6so1654877ywa.82 for ; Mon, 28 Jul 2008 10:41:16 -0700 (PDT) Message-ID: Date: Mon, 28 Jul 2008 20:41:15 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] Re: [PATCH 0/3]: Add UUID command-line option In-Reply-To: <20080728162701.GC23771@minantech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <488DC8B2.1070009@redhat.com> <488DD98D.5010907@codemonkey.ws> <488DDA93.4070702@redhat.com> <488DDF8B.8020103@codemonkey.ws> <488DE142.1060100@redhat.com> <488DE1E0.1070005@codemonkey.ws> <488DE8D4.5020502@redhat.com> <20080728160215.GB23771@minantech.com> <488DF11D.7090100@codemonkey.ws> <20080728162701.GC23771@minantech.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Chris Lalancette On 7/28/08, Gleb Natapov wrote: > On Mon, Jul 28, 2008 at 11:17:33AM -0500, Anthony Liguori wrote: > > Gleb Natapov wrote: > >> > >> CMOS has enough memory for UUID, but UUID is not the only thing that > >> needs to be passed to BIOS, so eventually we can run out of space there. > >> > > > > I'm inclined to think that on a real machine, the UUID is stored in the > > CMOS. > > > > Should be easy to check. > > > >> For example we have a requirement to pass additional ACPI tables that > >> user may specify on command line. > > > > What's the use-case? I don't think this is a very good idea. > > > > AFAIK some OEM version of windows needs special ACPI table for > activation. > > > >> There is no enough space to put those > >> tables into CMOS. What I did is that: BIOS passes to qemu address where to > >> store additional tables (via backdoor) and qemu copies them there. To > >> this scheme to work there should be bidirectional channel between qemu > >> and BIOS. Other then that I am not particularly attached to vmware > >> backdoor :) > >> > > > > You can not arbitrarily extend the backdoor interface. It's an > > interface defined and controlled by VMware. If you extend it, you risk > > breaking other OSes that are assuming that interface has a different > > meaning. > > > > I am not disagreeing with you. Lets define another interface that is > acceptable by everyone here and I (or somebody else) will implement it. I propose to extend hw/firmware_abi.h structure to cover x86 needs in addition to Sparc32, Sparc64 and PPC. The structure could reside in a ROM somewhere, pointer to it could be in CMOS.