From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38150 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5kBj-0004M8-Jb for qemu-devel@nongnu.org; Tue, 12 Oct 2010 15:07:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5kBi-0006G7-BO for qemu-devel@nongnu.org; Tue, 12 Oct 2010 15:07:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5kBi-0006Fd-4K for qemu-devel@nongnu.org; Tue, 12 Oct 2010 15:07:02 -0400 Date: Tue, 12 Oct 2010 21:06:57 +0200 From: Gleb Natapov Subject: Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios Message-ID: <20101012190657.GG5218@redhat.com> References: <4CB36A20.5020106@codemonkey.ws> <20101011195955.GA5218@redhat.com> <4CB373DD.50307@codemonkey.ws> <4CB37E6E.8010106@zytor.com> <20101012080124.GY2397@redhat.com> <4CB48DCC.80804@zytor.com> <20101012165658.GE5218@redhat.com> <20101012174121.GF5218@redhat.com> <4CB49ED6.5000202@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CB49ED6.5000202@zytor.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "H. Peter Anvin" Cc: Kevin Wolf , seabios@seabios.org, qemu-devel@nongnu.org On Tue, Oct 12, 2010 at 10:45:58AM -0700, H. Peter Anvin wrote: > On 10/12/2010 10:41 AM, Gleb Natapov wrote: > > On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote: > >> On real hardware it is shared between BIOS and the OS, actually. > >> > > Guest OS can write in qemu CMOS too. But what is it useful for? Most of > > its content is not standard AFAIK. > > > > This is true to some extent -- there is some standard content, and some > further can be described via ACPI tables. However, my point was mostly > that it is an existing model for nonvolatile storage which also works on > hardware (and is vastly simpler albeit smaller in size than ESCD). > And my point is why would we want nonvolatile storage for BIOS settings in qemu. It doesn't provide anything that can't be done through command line and configured nicely by virt-manager and it introduces one more file to carry around with your VM. And if the idea is to create it on the fly then it is no longer nonvolatile and is not better then fw_cfg. If we want nonvolatile storage for some reason I would agree that CMOS is good candidate for that except of its size. How much can you fit into 128 byte? Less then one tweet. -- Gleb.