From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52185 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5iqt-0007LC-Tn for qemu-devel@nongnu.org; Tue, 12 Oct 2010 13:41:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5iqs-0005OD-KL for qemu-devel@nongnu.org; Tue, 12 Oct 2010 13:41:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5iqs-0005Nu-Cn for qemu-devel@nongnu.org; Tue, 12 Oct 2010 13:41:26 -0400 Date: Tue, 12 Oct 2010 19:41:21 +0200 From: Gleb Natapov Subject: Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios Message-ID: <20101012174121.GF5218@redhat.com> References: <4CB2FDF2.1020705@redhat.com> <20101011121634.GB28008@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: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. > "Gleb Natapov" wrote: > > >On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote: > >> On 10/12/2010 01:01 AM, Gleb Natapov wrote: > >> > On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote: > >> >>> I don't disagree. > >> >>> > >> >>> I think the best thing to do is to let SeaBIOS create a boot order table > >> >>> that contains descriptive information and then advertise that to QEMU. > >> >>> > >> >>> QEMU can then try to associate the list of bootable devices with it's > >> >>> own set of devices and select a preferred order that it can then give > >> >>> back to SeaBIOS. SeaBIOS can then present that list to the user for > >> >>> additional refinement. > >> >> > >> >> Really, this kind of comes down to having a data structure that anything > >> >> (Qemu, SeaBIOS and if needed the guest OS) can read and modify as needed. > >> >> > >> > But then QEMU and seabios will have to have shared storage they can > >> > both write too. And this shared storage is part of VM now so you need > >> > to carry it around when you move your VM elsewhere. > >> > > >> > >> Yes, and it's part of real hardware, too. It's usually called "the > >> CMOS", short for CMOS RAM. > >> > >On real hardware it is not shared between HW and bios. It is > >written/read only by BIOS. In qemu it is not persistent and generated > >for each qemu invocation. Previously it was used to pass config params > >from qemu to a bios (and some legacy params are still passed that way), > >but we moved to better interface for that (firmware config). > > > >-- > > Gleb. > > -- > Sent from my mobile phone. Please pardon any lack of formatting. -- Gleb.