[SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios
Anthony Liguori
anthony at codemonkey.ws
Mon Oct 11 21:51:09 CEST 2010
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.
Regards,
Anthony Liguori
> cheers,
> Gerd
>
More information about the SeaBIOS
mailing list