From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54042 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P5OZn-00011Y-Eu
	for qemu-devel@nongnu.org; Mon, 11 Oct 2010 16:02:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <gleb@redhat.com>) id 1P5OZT-0003WI-DU
	for qemu-devel@nongnu.org; Mon, 11 Oct 2010 16:02:26 -0400
Received: from mx1.redhat.com ([209.132.183.28]:58342)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gleb@redhat.com>) id 1P5OZT-0003W8-6X
	for qemu-devel@nongnu.org; Mon, 11 Oct 2010 16:02:07 -0400
Date: Mon, 11 Oct 2010 22:02:00 +0200
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios
Message-ID: <20101011200200.GB5218@redhat.com>
References: <20101011101855.GA25030@redhat.com> <4CB2E7D0.1010702@redhat.com>
	<4CB2FDF2.1020705@redhat.com> <4CB36AAD.7030101@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4CB36AAD.7030101@codemonkey.ws>
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>, seabios@seabios.org, Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org

On Mon, Oct 11, 2010 at 02:51:09PM -0500, Anthony Liguori wrote:
> On 10/11/2010 07:07 AM, Gerd Hoffmann wrote:
> >  Hi,
> >
> >>Floppy? Yes, I think we do.
> >
> >And *one* floppy controllers can actually have *two* drives
> >connected, although booting from 'b' doesn't work IIRC.
> >
> >>>and since one PCI device may
> >>>control more then one disk (ATA slave/master, SCSI LUNs). We
> >>>can do what
> >>>EDD specification does. Describe disk as:
> >>>     bus type (isa/pci),
> >>>     address on a bus (16 bit base address for isa, b/s/f for pci)
> >>>     device type (ATA/SCSI/VIRTIO)
> >>>     device path (slave/master for ATA, LUN for SCSI, nothing
> >>>for virtio)
> >>
> >>If we had a qdev ID for all devices (which I think we should have
> >>anyway), would this work or is a string not really handy enough?
> >
> >I think we'll need support for that in all drivers supporting boot
> >anyway, i.e. have virtio-blk-pci register a boot edd when
> >configured that way.  Question is how to configure this.  We could
> >attach the boot index to either the blockdev or the device, i.e.
> >
> >  -blockdev foo,bootindex=1
> >
> >or
> >
> >  -device virtio-blk-pci,bootindex=1
> >
> >The latter looks more useful to me, boot order is guest state
> >imho, also it might expand to PXE booting nicely, i.e.
> >
> >  -device e1000,bootindex=2
> >
> >Which turns up the question how this plays with option roms.
> >seabios should be able to order at pci device level at least when
> >booting via (pci) option rom.  OK for nics.  Booting from a scsi
> >disk with id != 0 using the lsi rom is probably impossible though.
> >
> >What about non-pci option roms?  The one used for -kernel for example?
> 
> -kernel hijacks int19 so it cannot participate in any kind of boot
> order.  It's either present (and therefore the bootable disk) or not
> present.
> 
-kernel is special enough to not care. Although it would be nice to fix
it to behave like regular boot rom.

--
			Gleb.