From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNYtt-0003CN-Ug for qemu-devel@nongnu.org; Mon, 28 Jul 2008 16:00:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNYtr-0003BQ-Gc for qemu-devel@nongnu.org; Mon, 28 Jul 2008 16:00:57 -0400 Received: from [199.232.76.173] (port=38716 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNYtr-0003BL-Bj for qemu-devel@nongnu.org; Mon, 28 Jul 2008 16:00:55 -0400 Received: from mail2.shareable.org ([80.68.89.115]:38348) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KNYtq-0002y8-Jf for qemu-devel@nongnu.org; Mon, 28 Jul 2008 16:00:55 -0400 Date: Mon, 28 Jul 2008 21:00:39 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH 0/3]: Add UUID command-line option Message-ID: <20080728200039.GA19216@shareable.org> References: <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> <20080728162828.GA14004@shareable.org> <488E17E0.6010701@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488E17E0.6010701@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. > > > > It may be part of the ROM that gets written to CMOS when you "reset to > factory defaults". I can think of a number of advantages to storing it > in CMOS. I thought the point of UUID is you're not supposed to be able to change it on real hardware. If it's in CMOS, and OSes/BIOS read it from CMOS, then it's easy to change. > >For testing guest ACPI implementations or changing their behaviour? :-) > > Sounds like a fantastic way for a user to shoot themselves in the foot. As if the other QEMU options are not like that :-) > If you care to do this sort of work, you can certainly recompile the > BIOS. The source is there afterall. Indeed, same goes for all the other QEMU options. The question is whether it's useful enough to have an option, or obscure enough not to. I'm inclined to think modifying ACPI tables is obscure, except perhaps for specific tweaks that some versions of Windows or Linux might need to run correctly, or to prevent them from using some hardware feature or other. -- Jamie