[SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios
gleb at redhat.com
Mon Oct 11 22:02:00 CEST 2010
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
> > -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
-kernel is special enough to not care. Although it would be nice to fix
it to behave like regular boot rom.
More information about the SeaBIOS