From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNVYu-0005uC-Fl for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:27:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNVYt-0005u0-LC for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:27:03 -0400 Received: from [199.232.76.173] (port=55178 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNVYt-0005tv-Hf for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:27:03 -0400 Received: from il.qumranet.com ([212.179.150.194]:20786) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNVYt-0005X3-Bp for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:27:03 -0400 Date: Mon, 28 Jul 2008 19:27:01 +0300 From: Gleb Natapov Message-ID: <20080728162701.GC23771@minantech.com> References: <488DC8B2.1070009@redhat.com> <20080728141515.GJ3196@minantech.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488DF11D.7090100@codemonkey.ws> Subject: [Qemu-devel] Re: [PATCH 0/3]: Add UUID command-line option 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: Chris Lalancette , "qemu-devel@nongnu.org" 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. -- Gleb.