From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNVaN-0006Kw-8G for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:28:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNVaL-0006Kd-Oa for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:28:33 -0400 Received: from [199.232.76.173] (port=55214 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNVaL-0006Ka-Hu for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:28:33 -0400 Received: from mail2.shareable.org ([80.68.89.115]:40296) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KNVaL-0005s1-JG for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:28:33 -0400 Date: Mon, 28 Jul 2008 17:28:28 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH 0/3]: Add UUID command-line option Message-ID: <20080728162828.GA14004@shareable.org> 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> 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: Gleb Natapov , Chris Lalancette Anthony Liguori 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. I'd imagine on a real machine the UUID cannot be changed, so it can't be stored in the CMOS. It's probably in the BIOS somewhere. I quick Google suggests at least some systems store it in the SMBIOS information, which is part of the BIOS EEPROM. It also suggested that some Dell laptops store it in the keyboard controller! The logical equivalent would be to directly write the UUID (and other) information into the Bochs BIOS when loading it into the emulator. > >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. For testing guest ACPI implementations or changing their behaviour? :-) > 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 agree, better to define a sensible interface if extensions are desired. Probably at least one other VM has defined such a thing, it would be good to copy if there is one and it's extensible. -- Jamie