From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNY0J-0005a5-7N for qemu-devel@nongnu.org; Mon, 28 Jul 2008 15:03:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNY0I-0005Zr-OH for qemu-devel@nongnu.org; Mon, 28 Jul 2008 15:03:30 -0400 Received: from [199.232.76.173] (port=59981 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNY0I-0005Zo-Ca for qemu-devel@nongnu.org; Mon, 28 Jul 2008 15:03:30 -0400 Received: from an-out-0708.google.com ([209.85.132.242]:62739) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNY0H-0002hr-S3 for qemu-devel@nongnu.org; Mon, 28 Jul 2008 15:03:29 -0400 Received: by an-out-0708.google.com with SMTP id d18so1709907and.130 for ; Mon, 28 Jul 2008 12:03:29 -0700 (PDT) Message-ID: <488E17E0.6010701@codemonkey.ws> Date: Mon, 28 Jul 2008 14:02:56 -0500 From: Anthony Liguori 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> <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> In-Reply-To: <20080728162828.GA14004@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: qemu-devel@nongnu.org Cc: Gleb Natapov , Chris Lalancette Jamie Lokier wrote: > 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 quick Google suggests at least some systems store it in the SMBIOS > information, which is part of the BIOS EEPROM. Well it definitely is part of the SMBIOS tables. The question is whether those tables are dynamically generated. I'm pretty sure they are for certain BIOSes. > For testing guest ACPI implementations or changing their behaviour? :-) > Sounds like a fantastic way for a user to shoot themselves in the foot. If you care to do this sort of work, you can certainly recompile the BIOS. The source is there afterall. Regards, Anthony Liguori >> 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 > > >