From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=36978 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P5Zrk-0002mc-Lw
	for qemu-devel@nongnu.org; Tue, 12 Oct 2010 04:05:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <gleb@redhat.com>) id 1P5Znd-0002GK-9P
	for qemu-devel@nongnu.org; Tue, 12 Oct 2010 04:01:30 -0400
Received: from mx1.redhat.com ([209.132.183.28]:58530)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gleb@redhat.com>) id 1P5Znd-0002GE-2f
	for qemu-devel@nongnu.org; Tue, 12 Oct 2010 04:01:29 -0400
Date: Tue, 12 Oct 2010 10:01:24 +0200
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to
	seabios
Message-ID: <20101012080124.GY2397@redhat.com>
References: <20101011101855.GA25030@redhat.com> <4CB2E7D0.1010702@redhat.com>
	<4CB2FDF2.1020705@redhat.com> <20101011121634.GB28008@redhat.com>
	<4CB36A20.5020106@codemonkey.ws> <20101011195955.GA5218@redhat.com>
	<4CB373DD.50307@codemonkey.ws> <4CB37E6E.8010106@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4CB37E6E.8010106@zytor.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kevin Wolf <kwolf@redhat.com>, seabios@seabios.org, qemu-devel@nongnu.org

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.
 
--
			Gleb.