[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