From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNVAx-00056l-Qf for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:02:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNVAv-00055U-Vz for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:02:19 -0400 Received: from [199.232.76.173] (port=37223 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNVAv-00055M-Kg for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:02:17 -0400 Received: from il.qumranet.com ([212.179.150.194]:15153) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNVAv-0008Kk-9t for qemu-devel@nongnu.org; Mon, 28 Jul 2008 12:02:17 -0400 Date: Mon, 28 Jul 2008 19:02:15 +0300 From: Gleb Natapov Message-ID: <20080728160215.GB23771@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488DE8D4.5020502@redhat.com> 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: Chris Lalancette Cc: qemu-devel@nongnu.org On Mon, Jul 28, 2008 at 05:42:12PM +0200, Chris Lalancette wrote: > Anthony Liguori wrote: > > > > That makes me sad that they merged that. What a terribly complicated > > way to do something that's relatively simple. > > Heh. OK. Well, that's where we are today, which may not be the best place, but > it's where both Gleb and I based the work off of. > > I'll ask a naive question about CMOS; is there room in a standard CMOS to store > a UUID? From my limited knowledge about it, I thought the CMOS was a quite > small region of ROM, and so there wouldn't really be room for something like a > 128-byte UUID. I could be totally wrong about that, though. > 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. For example we have a requirement to pass additional ACPI tables that user may specify on command line. 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 :) -- Gleb.