[Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

Currently if VM is started with multiple disks it is almost impossible to
guess which one of them will be used as boot device especially if there
is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
and without looking into the code you can't tell what the order will
be (and in qemu-kvm if boot=on is used it brings even more havoc). We
should allow fine-grained control of boot order from qemu command line,
or as a minimum control what device will be used for booting.

To do that along with inventing syntax to specify boot order on qemu
command line we need to communicate boot order to seabios via fw_cfg
interface. For that we need to have a way to unambiguously specify a
disk from qemu to seabios.  PCI bus address is not enough since not all
devices are PCI (do we care about them?) 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)

Will it cover all use cased? Any other ideas? Any ideas about qemu
command line syntax? May be somebody whats to implement it? :)

--
			Gleb.

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Kevin Wolf]

Am 11.10.2010 12:18, schrieb Gleb Natapov:
> Currently if VM is started with multiple disks it is almost impossible to
> guess which one of them will be used as boot device especially if there
> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> and without looking into the code you can't tell what the order will
> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> should allow fine-grained control of boot order from qemu command line,
> or as a minimum control what device will be used for booting.
> 
> To do that along with inventing syntax to specify boot order on qemu
> command line we need to communicate boot order to seabios via fw_cfg
> interface. For that we need to have a way to unambiguously specify a
> disk from qemu to seabios.  PCI bus address is not enough since not all
> devices are PCI (do we care about them?) 

Floppy? Yes, I think we do.

> 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?

Kevin

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 12:32:48PM +0200, Kevin Wolf wrote:
> Am 11.10.2010 12:18, schrieb Gleb Natapov:
> > Currently if VM is started with multiple disks it is almost impossible to
> > guess which one of them will be used as boot device especially if there
> > is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> > and without looking into the code you can't tell what the order will
> > be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> > should allow fine-grained control of boot order from qemu command line,
> > or as a minimum control what device will be used for booting.
> > 
> > To do that along with inventing syntax to specify boot order on qemu
> > command line we need to communicate boot order to seabios via fw_cfg
> > interface. For that we need to have a way to unambiguously specify a
> > disk from qemu to seabios.  PCI bus address is not enough since not all
> > devices are PCI (do we care about them?) 
> 
> Floppy? Yes, I think we do.
> 
> > 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?
> 
Given qdev ID how seabios knows what device it corresponds to?

--
			Gleb.

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Kevin Wolf]

Am 11.10.2010 12:43, schrieb Gleb Natapov:
> On Mon, Oct 11, 2010 at 12:32:48PM +0200, Kevin Wolf wrote:
>> Am 11.10.2010 12:18, schrieb Gleb Natapov:
>>> Currently if VM is started with multiple disks it is almost impossible to
>>> guess which one of them will be used as boot device especially if there
>>> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
>>> and without looking into the code you can't tell what the order will
>>> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
>>> should allow fine-grained control of boot order from qemu command line,
>>> or as a minimum control what device will be used for booting.
>>>
>>> To do that along with inventing syntax to specify boot order on qemu
>>> command line we need to communicate boot order to seabios via fw_cfg
>>> interface. For that we need to have a way to unambiguously specify a
>>> disk from qemu to seabios.  PCI bus address is not enough since not all
>>> devices are PCI (do we care about them?) 
>>
>> Floppy? Yes, I think we do.
>>
>>> 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?
>>
> Given qdev ID how seabios knows what device it corresponds to?

Right, somehow I assumed that SeaBIOS already has some information about
disks, but now I see that this is exactly the problem you're talking
about. My suggestion wasn't really helpful then.

I think what you described is more or less the only way to do it then.

Kevin

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gerd Hoffmann]

   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?

cheers,
   Gerd

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 02:07:14PM +0200, 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
> 
Yes, boot order is a guest sate managed by BIOS on real HW.

> 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?
> 
-option-rom rom.bin,bootindex=3?

We can pass boot index along with option rom via fw_cfg interface.

--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Anthony Liguori]

On 10/11/2010 07:16 AM, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 02:07:14PM +0200, 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
>>
>>      
> Yes, boot order is a guest sate managed by BIOS on real HW.
>    

It's not that simple.  On advanced platforms, the boot order can be 
stored outside of the BIOS.  For instance, the boot order is actually 
stored in the IMM on certain IBM platforms and the BIOS queries the IMM 
for the boot order.  This allows out-of-band management tools to alter 
the boot order.

This is more or less what we're looking for here.  The BIOS should be 
able to query and modify the boot order but this is something that 
ideally belongs in QEMU.

>> 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?
>>
>>      
> -option-rom rom.bin,bootindex=3?
>
> We can pass boot index along with option rom via fw_cfg interface.
>    

If the option rom is just hijacking int19, then there is no meaningful 
order you can give it.

Regards,

Anthony Liguori

> --
> 			Gleb.
>
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
>    

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 02:48:48PM -0500, Anthony Liguori wrote:
> On 10/11/2010 07:16 AM, Gleb Natapov wrote:
> >On Mon, Oct 11, 2010 at 02:07:14PM +0200, 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
> >>
> >Yes, boot order is a guest sate managed by BIOS on real HW.
> 
> It's not that simple.  On advanced platforms, the boot order can be
> stored outside of the BIOS.  For instance, the boot order is
> actually stored in the IMM on certain IBM platforms and the BIOS
> queries the IMM for the boot order.  This allows out-of-band
> management tools to alter the boot order.
> 
Interesting.

> This is more or less what we're looking for here.  The BIOS should
> be able to query and modify the boot order but this is something
> that ideally belongs in QEMU.
> 
> >>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?
> >>
> >-option-rom rom.bin,bootindex=3?
> >
> >We can pass boot index along with option rom via fw_cfg interface.
> 
> If the option rom is just hijacking int19, then there is no
> meaningful order you can give it.
> 

No boot rom should do that. extboot wreaks havoc when it is used.
And since virtio is now supported by bios there is no reason to use it.
Whoever needs scsi boot should add it to seabios too.

--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Anthony Liguori]

On 10/11/2010 02:59 PM, Gleb Natapov wrote:
> No boot rom should do that. extboot wreaks havoc when it is used.
> And since virtio is now supported by bios there is no reason to use it.
>    

You don't really have a choice.  You could be doing hardware passthrough 
and the ROM on the card may hijack int19.

> Whoever needs scsi boot should add it to seabios too.
>    

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.

Regards,

Anthony Liguori

> --
> 			Gleb.
>    

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 03:30:21PM -0500, Anthony Liguori wrote:
> On 10/11/2010 02:59 PM, Gleb Natapov wrote:
> >No boot rom should do that. extboot wreaks havoc when it is used.
> >And since virtio is now supported by bios there is no reason to use it.
> 
> You don't really have a choice.  You could be doing hardware
> passthrough and the ROM on the card may hijack int19.
> 
Then this particular HW would be broken on real HW too and will not
respect BIOS settings. But the code we provide should work properly.

> >Whoever needs scsi boot should add it to seabios too.
> 
> 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.
> 
What for? Why this step is needed?

> 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.
> 
Why not skip your first step and let QEMU create boot order list and
pass it into Seabios. If menu=on option is present user will be able to
override the default from Seabios.

--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Anthony Liguori]

On 10/11/2010 03:36 PM, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 03:30:21PM -0500, Anthony Liguori wrote:
>    
>> On 10/11/2010 02:59 PM, Gleb Natapov wrote:
>>      
>>> No boot rom should do that. extboot wreaks havoc when it is used.
>>> And since virtio is now supported by bios there is no reason to use it.
>>>        
>> You don't really have a choice.  You could be doing hardware
>> passthrough and the ROM on the card may hijack int19.
>>
>>      
> Then this particular HW would be broken on real HW too and will not
> respect BIOS settings. But the code we provide should work properly.
>
>    
>>> Whoever needs scsi boot should add it to seabios too.
>>>        
>> 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.
>>
>>      
> What for? Why this step is needed?
>
>    
>> 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.
>>
>>      
> Why not skip your first step and let QEMU create boot order list and
> pass it into Seabios. If menu=on option is present user will be able to
> override the default from Seabios.
>    

Because SeaBIOS is definitive and QEMU is not.

We can ask SeaBIOS to boot from SCSI LUN 3 on PCI address X.Y.Z but that 
doesn't mean that it can figure out what that means.  If it can't, how 
do we communicate that to the user?  If SeaBIOS communicates its list to 
QEMU then we can at least display that list in the monitor in the same 
way that it's displayed to the guest.  That means that we can reorder in 
the monitor and potentially can persistent the boot device list in a 
more meaningful way.

Regards,

Anthony Liguori

> --
> 			Gleb.
>    

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 03:50:08PM -0500, Anthony Liguori wrote:
> On 10/11/2010 03:36 PM, Gleb Natapov wrote:
> >On Mon, Oct 11, 2010 at 03:30:21PM -0500, Anthony Liguori wrote:
> >>On 10/11/2010 02:59 PM, Gleb Natapov wrote:
> >>>No boot rom should do that. extboot wreaks havoc when it is used.
> >>>And since virtio is now supported by bios there is no reason to use it.
> >>You don't really have a choice.  You could be doing hardware
> >>passthrough and the ROM on the card may hijack int19.
> >>
> >Then this particular HW would be broken on real HW too and will not
> >respect BIOS settings. But the code we provide should work properly.
> >
> >>>Whoever needs scsi boot should add it to seabios too.
> >>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.
> >>
> >What for? Why this step is needed?
> >
> >>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.
> >>
> >Why not skip your first step and let QEMU create boot order list and
> >pass it into Seabios. If menu=on option is present user will be able to
> >override the default from Seabios.
> 
> Because SeaBIOS is definitive and QEMU is not.
> 
> We can ask SeaBIOS to boot from SCSI LUN 3 on PCI address X.Y.Z but
> that doesn't mean that it can figure out what that means.  If it
It can figure exactly what that means. This defines boot disk in
non-ambiguous way.

> can't, how do we communicate that to the user?  If SeaBIOS
Boot will fail, user will notice. Actually there is an idea to notify
qemu about failed boot instead of just halt in bios. But, in reality,
since qemu and seabios are released together this situation should
never happen. If device is created by qemu it should be enumerated by
seabios. Otherwise other things may not work properly too.

> communicates its list to QEMU then we can at least display that list
> in the monitor in the same way that it's displayed to the guest.
You can display it on the monitor. Qemu has all necessary info. Qemu
creates it and pass into seabios after all.

> That means that we can reorder in the monitor and potentially can
> persistent the boot device list in a more meaningful way.
You can reorder them in the monitor between boots just fine without
passing any info from Seabios to QEMU.

Seabios does not create any bootable devices, it just discovers whatever
qemu created, so seabios has nothing interesting to tell to qemu.

--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On 10/11/2010 01:30 PM, Anthony Liguori wrote:
> On 10/11/2010 02:59 PM, Gleb Natapov wrote:
>> No boot rom should do that. extboot wreaks havoc when it is used.
>> And since virtio is now supported by bios there is no reason to use it.
> 
> You don't really have a choice.  You could be doing hardware passthrough 
> and the ROM on the card may hijack int19.

The BBS standard actually documents how to deal with that -- it pretty
much works out to "let the card initialize, then see if it mucked with
int19, and then put int19 back... if we want to run that card, then we
invoke the int19 that the card set up."

>> Whoever needs scsi boot should add it to seabios too.
>>    
> 
> 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.

	-hpa

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Sebastian Herbszt]

H. Peter Anvin wrote:
> On 10/11/2010 01:30 PM, Anthony Liguori wrote:
>> On 10/11/2010 02:59 PM, Gleb Natapov wrote:
>>> No boot rom should do that. extboot wreaks havoc when it is used.
>>> And since virtio is now supported by bios there is no reason to use it.
>> 
>> You don't really have a choice.  You could be doing hardware passthrough 
>> and the ROM on the card may hijack int19.
> 
> The BBS standard actually documents how to deal with that -- it pretty
> much works out to "let the card initialize, then see if it mucked with
> int19, and then put int19 back... if we want to run that card, then we
> invoke the int19 that the card set up."

The BIOS Boot Specification, Version 1.01 from January 11, 1996 seems not to
recommend this:

3.4 Legacy IPL Devices

"Legacy IPL devices will be allowed to take control of the system (via hooking
interrupts) in both Legacy and PnP systems. The Plug and Play BIOS specification
recommends that Legacy devices that hook a bootstrap interrupt such as INT 19h, 18h,
or 13h have the interrupt re-captured by the BIOS. This is not done because grabbing
an interrupt vector back after a device has hooked it can produce unpredictable results.
Further, by allowing the card to take control, the behavior of these Legacy cards will
be the same on both PnP and Legacy machines."

6.8 Notes on the POST Process

"The Plug and Play BIOS Specification says that if a Legacy IPL device's option
ROM captures INT 18h or INT 19h, the BIOS should save this vector and then
restore the original one put there by the BIOS. The BIOS Boot Specification
deviates from this in that these vectors are not recaptured after each Legacy option
ROM returns from initialization. That would be considered unsafe."

Sebastian

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On 10/11/2010 02:41 PM, Sebastian Herbszt wrote:
> H. Peter Anvin wrote:
>> On 10/11/2010 01:30 PM, Anthony Liguori wrote:
>>> On 10/11/2010 02:59 PM, Gleb Natapov wrote:
>>>> No boot rom should do that. extboot wreaks havoc when it is used.
>>>> And since virtio is now supported by bios there is no reason to use it.
>>>
>>> You don't really have a choice.  You could be doing hardware passthrough 
>>> and the ROM on the card may hijack int19.
>>
>> The BBS standard actually documents how to deal with that -- it pretty
>> much works out to "let the card initialize, then see if it mucked with
>> int19, and then put int19 back... if we want to run that card, then we
>> invoke the int19 that the card set up."
> 
> The BIOS Boot Specification, Version 1.01 from January 11, 1996 seems not to
> recommend this:
> 
> 3.4 Legacy IPL Devices
> 
> "Legacy IPL devices will be allowed to take control of the system (via hooking
> interrupts) in both Legacy and PnP systems. The Plug and Play BIOS specification
> recommends that Legacy devices that hook a bootstrap interrupt such as INT 19h, 18h,
> or 13h have the interrupt re-captured by the BIOS. This is not done because grabbing
> an interrupt vector back after a device has hooked it can produce unpredictable results.
> Further, by allowing the card to take control, the behavior of these Legacy cards will
> be the same on both PnP and Legacy machines."
> 
> 6.8 Notes on the POST Process
> 
> "The Plug and Play BIOS Specification says that if a Legacy IPL device's option
> ROM captures INT 18h or INT 19h, the BIOS should save this vector and then
> restore the original one put there by the BIOS. The BIOS Boot Specification
> deviates from this in that these vectors are not recaptured after each Legacy option
> ROM returns from initialization. That would be considered unsafe."
> 

Sorry, you're right -- I confused the PNPBIOS spec with the BBS spec
(and compounded the error by correctly remembering that BBS overrides
PNPBIOS).

	-hpa

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

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.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On 10/12/2010 01:01 AM, Gleb Natapov wrote:
> 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.
>  

Yes, and it's part of real hardware, too.  It's usually called "the
CMOS", short for CMOS RAM.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote:
> On 10/12/2010 01:01 AM, Gleb Natapov wrote:
> > 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.
> >  
> 
> Yes, and it's part of real hardware, too.  It's usually called "the
> CMOS", short for CMOS RAM.
> 
On real hardware it is not shared between HW and bios. It is
written/read only by BIOS. In qemu it is not persistent and generated
for each qemu invocation. Previously it was used to pass config params
from qemu to a bios (and some legacy params are still passed that way),
but we moved to better interface for that (firmware config).

--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On real hardware it is shared between BIOS and the OS, actually.

"Gleb Natapov" <gleb@redhat.com> wrote:

>On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote:
>> On 10/12/2010 01:01 AM, Gleb Natapov wrote:
>> > 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.
>> >  
>> 
>> Yes, and it's part of real hardware, too.  It's usually called "the
>> CMOS", short for CMOS RAM.
>> 
>On real hardware it is not shared between HW and bios. It is
>written/read only by BIOS. In qemu it is not persistent and generated
>for each qemu invocation. Previously it was used to pass config params
>from qemu to a bios (and some legacy params are still passed that way),
>but we moved to better interface for that (firmware config).
>
>--
>			Gleb.

-- 
Sent from my mobile phone.  Please pardon any lack of formatting.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote:
> On real hardware it is shared between BIOS and the OS, actually.
> 
Guest OS can write in qemu CMOS too. But what is it useful for? Most of
its content is not standard AFAIK.

> "Gleb Natapov" <gleb@redhat.com> wrote:
> 
> >On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote:
> >> On 10/12/2010 01:01 AM, Gleb Natapov wrote:
> >> > 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.
> >> >  
> >> 
> >> Yes, and it's part of real hardware, too.  It's usually called "the
> >> CMOS", short for CMOS RAM.
> >> 
> >On real hardware it is not shared between HW and bios. It is
> >written/read only by BIOS. In qemu it is not persistent and generated
> >for each qemu invocation. Previously it was used to pass config params
> >from qemu to a bios (and some legacy params are still passed that way),
> >but we moved to better interface for that (firmware config).
> >
> >--
> >			Gleb.
> 
> -- 
> Sent from my mobile phone.  Please pardon any lack of formatting.

--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On 10/12/2010 10:41 AM, Gleb Natapov wrote:
> On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote:
>> On real hardware it is shared between BIOS and the OS, actually.
>>
> Guest OS can write in qemu CMOS too. But what is it useful for? Most of
> its content is not standard AFAIK.
> 

This is true to some extent -- there is some standard content, and some
further can be described via ACPI tables.  However, my point was mostly
that it is an existing model for nonvolatile storage which also works on
hardware (and is vastly simpler albeit smaller in size than ESCD).

	-hpa

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Tue, Oct 12, 2010 at 10:45:58AM -0700, H. Peter Anvin wrote:
> On 10/12/2010 10:41 AM, Gleb Natapov wrote:
> > On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote:
> >> On real hardware it is shared between BIOS and the OS, actually.
> >>
> > Guest OS can write in qemu CMOS too. But what is it useful for? Most of
> > its content is not standard AFAIK.
> > 
> 
> This is true to some extent -- there is some standard content, and some
> further can be described via ACPI tables.  However, my point was mostly
> that it is an existing model for nonvolatile storage which also works on
> hardware (and is vastly simpler albeit smaller in size than ESCD).
> 
And my point is why would we want nonvolatile storage for BIOS settings
in qemu. It doesn't provide anything that can't be done through command
line and configured nicely by virt-manager and it introduces one more
file to carry around with your VM. And if the idea is to create it on
the fly then it is no longer nonvolatile and is not better then fw_cfg.
If we want nonvolatile storage for some reason I would agree that CMOS
is good candidate for that except of its size. How much can you fit into
128 byte? Less then one tweet.
--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On 10/12/2010 12:06 PM, Gleb Natapov wrote:
>>
>> This is true to some extent -- there is some standard content, and some
>> further can be described via ACPI tables.  However, my point was mostly
>> that it is an existing model for nonvolatile storage which also works on
>> hardware (and is vastly simpler albeit smaller in size than ESCD).
>>
> And my point is why would we want nonvolatile storage for BIOS settings
> in qemu. It doesn't provide anything that can't be done through command
> line and configured nicely by virt-manager and it introduces one more
> file to carry around with your VM. And if the idea is to create it on
> the fly then it is no longer nonvolatile and is not better then fw_cfg.
> If we want nonvolatile storage for some reason I would agree that CMOS
> is good candidate for that except of its size. How much can you fit into
> 128 byte? Less then one tweet.

128 bytes isn't a hard limit; the original PC/AT actually had only 64
bytes, but the "standard" interface allows 128 bytes.  However, there is
a semi-standard (common extension) interface using ports 72/73 which
allows 256 bytes, and quite a few chipsets have added further extensions.

The ACPI specification recognizes three interfaces as standard: PC/AT
(64 bytes, even though 128 bytes is available on a lot of platforms),
PIIX4 (256 bytes), and Dallas Semiconductor ("256 bytes or more").  The
interface for the latter isn't well cited in the ACPI spec, but I'm
guessing this is referring to the DS17885 series of chips, which can
have up to 8K CMOS using a bank-switched scheme which presents 128 bytes
at a time (thus accessible via only the standard 70/71 ports.)

	-hpa

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On 10/13/2010 12:17 PM, H. Peter Anvin wrote:
> 
> The ACPI specification recognizes three interfaces as standard: PC/AT
> (64 bytes, even though 128 bytes is available on a lot of platforms),
> PIIX4 (256 bytes), and Dallas Semiconductor ("256 bytes or more").  The
> interface for the latter isn't well cited in the ACPI spec, but I'm
> guessing this is referring to the DS17885 series of chips, which can
> have up to 8K CMOS using a bank-switched scheme which presents 128 bytes
> at a time (thus accessible via only the standard 70/71 ports.)
> 

FWIW, the DS17885 scheme actually allows addressing up to 64K; 8K is the
maximum that DS produced with this particular interface as far as I
know, but there are 16 address bits available.

	-hpa

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On 10/13/2010 01:00 PM, H. Peter Anvin wrote:
> On 10/13/2010 12:17 PM, H. Peter Anvin wrote:
>>
>> The ACPI specification recognizes three interfaces as standard: PC/AT
>> (64 bytes, even though 128 bytes is available on a lot of platforms),
>> PIIX4 (256 bytes), and Dallas Semiconductor ("256 bytes or more").  The
>> interface for the latter isn't well cited in the ACPI spec, but I'm
>> guessing this is referring to the DS17885 series of chips, which can
>> have up to 8K CMOS using a bank-switched scheme which presents 128 bytes
>> at a time (thus accessible via only the standard 70/71 ports.)
>>
> 
> FWIW, the DS17885 scheme actually allows addressing up to 64K; 8K is the
> maximum that DS produced with this particular interface as far as I
> know, but there are 16 address bits available.
> 
> 	-hpa

I think this is the relevant application note:

http://www.maxim-ic.com/app-notes/index.mvp/id/77

	-hpa

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Anthony Liguori]

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
>

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

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.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[H. Peter Anvin]

On 10/11/2010 12:51 PM, Anthony Liguori wrote:
> 
> -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.
> 

That's a misdesign, though: it should be able to participate in BBS as a
BEV.

	-hpa

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Bernhard Kohl]

Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
> Currently if VM is started with multiple disks it is almost impossible to
> guess which one of them will be used as boot device especially if there
> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> and without looking into the code you can't tell what the order will
> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> should allow fine-grained control of boot order from qemu command line,
> or as a minimum control what device will be used for booting.
>
> To do that along with inventing syntax to specify boot order on qemu
> command line we need to communicate boot order to seabios via fw_cfg
> interface. For that we need to have a way to unambiguously specify a
> disk from qemu to seabios.  PCI bus address is not enough since not all
> devices are PCI (do we care about them?) 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)
>
> Will it cover all use cased? Any other ideas?

I think this also applies to network booting via gPXE. Usually our VMs
have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
be used for booting, even if there are hard disks or floppy disks
connected. This scenario is currently almost impossible to configure.

I already posted a patch 'new parameter boot=on|off for "-net nic" and
"-device" NIC devices' which should solve that problem for us. The
patch is still under discussion. Of course passing detailed boot device
information to SeaBIOS would be the best solution.

> Any ideas about qemu
> command line syntax? May be somebody whats to implement it? :)
>
> --
> 			Gleb.
>
>    

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 01:16:00PM +0200, Bernhard Kohl wrote:
> Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
> >Currently if VM is started with multiple disks it is almost impossible to
> >guess which one of them will be used as boot device especially if there
> >is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> >and without looking into the code you can't tell what the order will
> >be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> >should allow fine-grained control of boot order from qemu command line,
> >or as a minimum control what device will be used for booting.
> >
> >To do that along with inventing syntax to specify boot order on qemu
> >command line we need to communicate boot order to seabios via fw_cfg
> >interface. For that we need to have a way to unambiguously specify a
> >disk from qemu to seabios.  PCI bus address is not enough since not all
> >devices are PCI (do we care about them?) 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)
> >
> >Will it cover all use cased? Any other ideas?
> 
> I think this also applies to network booting via gPXE. Usually our VMs
> have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
> be used for booting, even if there are hard disks or floppy disks
> connected. This scenario is currently almost impossible to configure.
> 
> I already posted a patch 'new parameter boot=on|off for "-net nic" and
> "-device" NIC devices' which should solve that problem for us. The
> patch is still under discussion. Of course passing detailed boot device
> information to SeaBIOS would be the best solution.
> 
Yeah, forgot to specify net booting specifically. Do we emulate usb
storage? If yes it can be bootable too. Sorry, I missed your patch
initially, but now looking at it I do not think this is right approach.
It resembles to me extboot hack. We shouldn't play games with roms to
specify boot order. Bios is able to handle this by itself, we just need
to help it. NIC can be specified by its bus address and may be virtual
function (for SR-IOV devices ?). Seabios will be able to find what
option rom it should run from there.

> >Any ideas about qemu
> >command line syntax? May be somebody whats to implement it? :)
> >
> >--
> >			Gleb.
> >

--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Kevin O'Connor]

On Mon, Oct 11, 2010 at 02:08:13PM +0200, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 01:16:00PM +0200, Bernhard Kohl wrote:
> > I think this also applies to network booting via gPXE. Usually our VMs
> > have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
> > be used for booting, even if there are hard disks or floppy disks
> > connected. This scenario is currently almost impossible to configure.
> > 
> > I already posted a patch 'new parameter boot=on|off for "-net nic" and
> > "-device" NIC devices' which should solve that problem for us. The
> > patch is still under discussion. Of course passing detailed boot device
> > information to SeaBIOS would be the best solution.
> > 
> Yeah, forgot to specify net booting specifically. Do we emulate usb
> storage? If yes it can be bootable too.

USB emultion is supported by qemu, and being able to specify a boot
from USB drive should be supported IMO.

-Kevin

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Stefan Hajnoczi]

On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl <bernhard.kohl@nsn.com> wrote:
> Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
>>
>> Currently if VM is started with multiple disks it is almost impossible to
>> guess which one of them will be used as boot device especially if there
>> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
>> and without looking into the code you can't tell what the order will
>> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
>> should allow fine-grained control of boot order from qemu command line,
>> or as a minimum control what device will be used for booting.
>>
>> To do that along with inventing syntax to specify boot order on qemu
>> command line we need to communicate boot order to seabios via fw_cfg
>> interface. For that we need to have a way to unambiguously specify a
>> disk from qemu to seabios.  PCI bus address is not enough since not all
>> devices are PCI (do we care about them?) 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)
>>
>> Will it cover all use cased? Any other ideas?
>
> I think this also applies to network booting via gPXE. Usually our VMs
> have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
> be used for booting, even if there are hard disks or floppy disks
> connected. This scenario is currently almost impossible to configure.

Here is a gPXE to support fw_cfg.  You can pass gPXE script files from
the host to gPXE inside the guest.  This means you can boot specific
NICs:
http://patchwork.ozlabs.org/patch/43777/

Just wanted to post the link because it is related to the gPXE side of
this discussion.

Stefan

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
> On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl <bernhard.kohl@nsn.com> wrote:
> > Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
> >>
> >> Currently if VM is started with multiple disks it is almost impossible to
> >> guess which one of them will be used as boot device especially if there
> >> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> >> and without looking into the code you can't tell what the order will
> >> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> >> should allow fine-grained control of boot order from qemu command line,
> >> or as a minimum control what device will be used for booting.
> >>
> >> To do that along with inventing syntax to specify boot order on qemu
> >> command line we need to communicate boot order to seabios via fw_cfg
> >> interface. For that we need to have a way to unambiguously specify a
> >> disk from qemu to seabios.  PCI bus address is not enough since not all
> >> devices are PCI (do we care about them?) 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)
> >>
> >> Will it cover all use cased? Any other ideas?
> >
> > I think this also applies to network booting via gPXE. Usually our VMs
> > have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
> > be used for booting, even if there are hard disks or floppy disks
> > connected. This scenario is currently almost impossible to configure.
> 
> Here is a gPXE to support fw_cfg.  You can pass gPXE script files from
> the host to gPXE inside the guest.  This means you can boot specific
> NICs:
> http://patchwork.ozlabs.org/patch/43777/
> 
> Just wanted to post the link because it is related to the gPXE side of
> this discussion.
> 
Don't we load gPXE for each NIC and seabios passes PCI device to boot from
when it invokes one of them?

--
			Gleb.

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Stefan Hajnoczi]

2010/10/11 Gleb Natapov <gleb@redhat.com>:
> On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
>> On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl <bernhard.kohl@nsn.com> wrote:
>> > Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
>> >>
>> >> Currently if VM is started with multiple disks it is almost impossible to
>> >> guess which one of them will be used as boot device especially if there
>> >> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
>> >> and without looking into the code you can't tell what the order will
>> >> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
>> >> should allow fine-grained control of boot order from qemu command line,
>> >> or as a minimum control what device will be used for booting.
>> >>
>> >> To do that along with inventing syntax to specify boot order on qemu
>> >> command line we need to communicate boot order to seabios via fw_cfg
>> >> interface. For that we need to have a way to unambiguously specify a
>> >> disk from qemu to seabios.  PCI bus address is not enough since not all
>> >> devices are PCI (do we care about them?) 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)
>> >>
>> >> Will it cover all use cased? Any other ideas?
>> >
>> > I think this also applies to network booting via gPXE. Usually our VMs
>> > have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
>> > be used for booting, even if there are hard disks or floppy disks
>> > connected. This scenario is currently almost impossible to configure.
>>
>> Here is a gPXE to support fw_cfg.  You can pass gPXE script files from
>> the host to gPXE inside the guest.  This means you can boot specific
>> NICs:
>> http://patchwork.ozlabs.org/patch/43777/
>>
>> Just wanted to post the link because it is related to the gPXE side of
>> this discussion.
>>
> Don't we load gPXE for each NIC and seabios passes PCI device to boot from
> when it invokes one of them?

SeaBIOS may do that but gPXE internally just probes all PCI devices.
It does not take advantage of the PCI bus/addr/fn that was passed to
the option ROM.  A gPXE instance will try booting from each available
NIC in sequence.

Stefan

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 04:52:31PM +0100, Stefan Hajnoczi wrote:
> 2010/10/11 Gleb Natapov <gleb@redhat.com>:
> > On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
> >> On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl <bernhard.kohl@nsn.com> wrote:
> >> > Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
> >> >>
> >> >> Currently if VM is started with multiple disks it is almost impossible to
> >> >> guess which one of them will be used as boot device especially if there
> >> >> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> >> >> and without looking into the code you can't tell what the order will
> >> >> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> >> >> should allow fine-grained control of boot order from qemu command line,
> >> >> or as a minimum control what device will be used for booting.
> >> >>
> >> >> To do that along with inventing syntax to specify boot order on qemu
> >> >> command line we need to communicate boot order to seabios via fw_cfg
> >> >> interface. For that we need to have a way to unambiguously specify a
> >> >> disk from qemu to seabios.  PCI bus address is not enough since not all
> >> >> devices are PCI (do we care about them?) 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)
> >> >>
> >> >> Will it cover all use cased? Any other ideas?
> >> >
> >> > I think this also applies to network booting via gPXE. Usually our VMs
> >> > have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
> >> > be used for booting, even if there are hard disks or floppy disks
> >> > connected. This scenario is currently almost impossible to configure.
> >>
> >> Here is a gPXE to support fw_cfg.  You can pass gPXE script files from
> >> the host to gPXE inside the guest.  This means you can boot specific
> >> NICs:
> >> http://patchwork.ozlabs.org/patch/43777/
> >>
> >> Just wanted to post the link because it is related to the gPXE side of
> >> this discussion.
> >>
> > Don't we load gPXE for each NIC and seabios passes PCI device to boot from
> > when it invokes one of them?
> 
> SeaBIOS may do that but gPXE internally just probes all PCI devices.
> It does not take advantage of the PCI bus/addr/fn that was passed to
> the option ROM.  A gPXE instance will try booting from each available
> NIC in sequence.

Ah, thanks for clarification. Looks like gPXE does the wrong thing here.
Can this behaviour be changed by compile time option?

--
			Gleb.

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Anthony Liguori]

On 10/11/2010 10:52 AM, Stefan Hajnoczi wrote:
> 2010/10/11 Gleb Natapov<gleb@redhat.com>:
>    
>> On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
>>      
>>> On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl<bernhard.kohl@nsn.com>  wrote:
>>>        
>>>> Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
>>>>          
>>>>> Currently if VM is started with multiple disks it is almost impossible to
>>>>> guess which one of them will be used as boot device especially if there
>>>>> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
>>>>> and without looking into the code you can't tell what the order will
>>>>> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
>>>>> should allow fine-grained control of boot order from qemu command line,
>>>>> or as a minimum control what device will be used for booting.
>>>>>
>>>>> To do that along with inventing syntax to specify boot order on qemu
>>>>> command line we need to communicate boot order to seabios via fw_cfg
>>>>> interface. For that we need to have a way to unambiguously specify a
>>>>> disk from qemu to seabios.  PCI bus address is not enough since not all
>>>>> devices are PCI (do we care about them?) 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)
>>>>>
>>>>> Will it cover all use cased? Any other ideas?
>>>>>            
>>>> I think this also applies to network booting via gPXE. Usually our VMs
>>>> have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
>>>> be used for booting, even if there are hard disks or floppy disks
>>>> connected. This scenario is currently almost impossible to configure.
>>>>          
>>> Here is a gPXE to support fw_cfg.  You can pass gPXE script files from
>>> the host to gPXE inside the guest.  This means you can boot specific
>>> NICs:
>>> http://patchwork.ozlabs.org/patch/43777/
>>>
>>> Just wanted to post the link because it is related to the gPXE side of
>>> this discussion.
>>>
>>>        
>> Don't we load gPXE for each NIC and seabios passes PCI device to boot from
>> when it invokes one of them?
>>      
> SeaBIOS may do that but gPXE internally just probes all PCI devices.
> It does not take advantage of the PCI bus/addr/fn that was passed to
> the option ROM.  A gPXE instance will try booting from each available
> NIC in sequence.
>    

It still registers a BEV entry though, no?

Does it at least try to boot from the PCI bus/addr/fn of the selected 
BEV entry?

Regards,

Anthony Liguori

> Stefan
>
>    

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 12:01:58PM -0500, Anthony Liguori wrote:
> On 10/11/2010 10:52 AM, Stefan Hajnoczi wrote:
> >2010/10/11 Gleb Natapov<gleb@redhat.com>:
> >>On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
> >>>On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl<bernhard.kohl@nsn.com>  wrote:
> >>>>Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
> >>>>>Currently if VM is started with multiple disks it is almost impossible to
> >>>>>guess which one of them will be used as boot device especially if there
> >>>>>is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> >>>>>and without looking into the code you can't tell what the order will
> >>>>>be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> >>>>>should allow fine-grained control of boot order from qemu command line,
> >>>>>or as a minimum control what device will be used for booting.
> >>>>>
> >>>>>To do that along with inventing syntax to specify boot order on qemu
> >>>>>command line we need to communicate boot order to seabios via fw_cfg
> >>>>>interface. For that we need to have a way to unambiguously specify a
> >>>>>disk from qemu to seabios.  PCI bus address is not enough since not all
> >>>>>devices are PCI (do we care about them?) 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)
> >>>>>
> >>>>>Will it cover all use cased? Any other ideas?
> >>>>I think this also applies to network booting via gPXE. Usually our VMs
> >>>>have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
> >>>>be used for booting, even if there are hard disks or floppy disks
> >>>>connected. This scenario is currently almost impossible to configure.
> >>>Here is a gPXE to support fw_cfg.  You can pass gPXE script files from
> >>>the host to gPXE inside the guest.  This means you can boot specific
> >>>NICs:
> >>>http://patchwork.ozlabs.org/patch/43777/
> >>>
> >>>Just wanted to post the link because it is related to the gPXE side of
> >>>this discussion.
> >>>
> >>Don't we load gPXE for each NIC and seabios passes PCI device to boot from
> >>when it invokes one of them?
> >SeaBIOS may do that but gPXE internally just probes all PCI devices.
> >It does not take advantage of the PCI bus/addr/fn that was passed to
> >the option ROM.  A gPXE instance will try booting from each available
> >NIC in sequence.
> 
> It still registers a BEV entry though, no?
> 
> Does it at least try to boot from the PCI bus/addr/fn of the
> selected BEV entry?
> 
I think so. Kevin will know for sure.

--
			Gleb.

Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Kevin O'Connor]

On Mon, Oct 11, 2010 at 07:04:25PM +0200, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 12:01:58PM -0500, Anthony Liguori wrote:
> > On 10/11/2010 10:52 AM, Stefan Hajnoczi wrote:
> > >SeaBIOS may do that but gPXE internally just probes all PCI devices.
> > >It does not take advantage of the PCI bus/addr/fn that was passed to
> > >the option ROM.  A gPXE instance will try booting from each available
> > >NIC in sequence.
> > 
> > It still registers a BEV entry though, no?
> > 
> > Does it at least try to boot from the PCI bus/addr/fn of the
> > selected BEV entry?
> > 
> I think so. Kevin will know for sure.

SeaBIOS will register a BEV for each gPXE option rom it finds, and the
user may choose which BEV to run first.  I don't know if gPXE cares
if different BEVs are run though.

-Kevin

Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios

[Stefan Hajnoczi]

On Mon, Oct 11, 2010 at 6:04 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Mon, Oct 11, 2010 at 12:01:58PM -0500, Anthony Liguori wrote:
>> On 10/11/2010 10:52 AM, Stefan Hajnoczi wrote:
>> >2010/10/11 Gleb Natapov<gleb@redhat.com>:
>> >>On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote:
>> >>>On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl<bernhard.kohl@nsn.com>  wrote:
>> >>>>Am 11.10.2010 12:18, schrieb ext Gleb Natapov:
>> >>>>>Currently if VM is started with multiple disks it is almost impossible to
>> >>>>>guess which one of them will be used as boot device especially if there
>> >>>>>is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
>> >>>>>and without looking into the code you can't tell what the order will
>> >>>>>be (and in qemu-kvm if boot=on is used it brings even more havoc). We
>> >>>>>should allow fine-grained control of boot order from qemu command line,
>> >>>>>or as a minimum control what device will be used for booting.
>> >>>>>
>> >>>>>To do that along with inventing syntax to specify boot order on qemu
>> >>>>>command line we need to communicate boot order to seabios via fw_cfg
>> >>>>>interface. For that we need to have a way to unambiguously specify a
>> >>>>>disk from qemu to seabios.  PCI bus address is not enough since not all
>> >>>>>devices are PCI (do we care about them?) 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)
>> >>>>>
>> >>>>>Will it cover all use cased? Any other ideas?
>> >>>>I think this also applies to network booting via gPXE. Usually our VMs
>> >>>>have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs shall
>> >>>>be used for booting, even if there are hard disks or floppy disks
>> >>>>connected. This scenario is currently almost impossible to configure.
>> >>>Here is a gPXE to support fw_cfg.  You can pass gPXE script files from
>> >>>the host to gPXE inside the guest.  This means you can boot specific
>> >>>NICs:
>> >>>http://patchwork.ozlabs.org/patch/43777/
>> >>>
>> >>>Just wanted to post the link because it is related to the gPXE side of
>> >>>this discussion.
>> >>>
>> >>Don't we load gPXE for each NIC and seabios passes PCI device to boot from
>> >>when it invokes one of them?
>> >SeaBIOS may do that but gPXE internally just probes all PCI devices.
>> >It does not take advantage of the PCI bus/addr/fn that was passed to
>> >the option ROM.  A gPXE instance will try booting from each available
>> >NIC in sequence.
>>
>> It still registers a BEV entry though, no?

Yes.

>> Does it at least try to boot from the PCI bus/addr/fn of the
>> selected BEV entry?

Not directly.  It probes all PCI devices and tries them in bus/addr/fn
order.  If you have two identical NICs and only have the boot ROM on
the second NIC, the first NIC will still try to network boot first.

Changing this behavior requires stashing away the bus/addr/fn and then
using it later in gPXE's startup.  It's possible but not implemented
today.

Stefan

[Qemu-devel] Re: [SeaBIOS] [RFC] Passing boot order from qemu to seabios

[Avi Kivity]

  On 10/11/2010 12:18 PM, Gleb Natapov wrote:
> Currently if VM is started with multiple disks it is almost impossible to
> guess which one of them will be used as boot device especially if there
> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> and without looking into the code you can't tell what the order will
> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> should allow fine-grained control of boot order from qemu command line,
> or as a minimum control what device will be used for booting.
>
> To do that along with inventing syntax to specify boot order on qemu
> command line we need to communicate boot order to seabios via fw_cfg
> interface. For that we need to have a way to unambiguously specify a
> disk from qemu to seabios.  PCI bus address is not enough since not all
> devices are PCI (do we care about them?) 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)
>
> Will it cover all use cased? Any other ideas? Any ideas about qemu
> command line syntax? May be somebody whats to implement it? :)

Instead of fwcfg, we should store the boot order in the bios.  This 
allows seabios to implement persistent boot selection and control boot 
order from within the guest.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [SeaBIOS] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 05:09:22PM +0200, Avi Kivity wrote:
>  On 10/11/2010 12:18 PM, Gleb Natapov wrote:
> >Currently if VM is started with multiple disks it is almost impossible to
> >guess which one of them will be used as boot device especially if there
> >is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> >and without looking into the code you can't tell what the order will
> >be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> >should allow fine-grained control of boot order from qemu command line,
> >or as a minimum control what device will be used for booting.
> >
> >To do that along with inventing syntax to specify boot order on qemu
> >command line we need to communicate boot order to seabios via fw_cfg
> >interface. For that we need to have a way to unambiguously specify a
> >disk from qemu to seabios.  PCI bus address is not enough since not all
> >devices are PCI (do we care about them?) 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)
> >
> >Will it cover all use cased? Any other ideas? Any ideas about qemu
> >command line syntax? May be somebody whats to implement it? :)
> 
> Instead of fwcfg, we should store the boot order in the bios.  This
> allows seabios to implement persistent boot selection and control
> boot order from within the guest.
> 
It is not "instead of" it is in a best case "in addition too". First of
all seabios does not have persistent storage currently and second I much
prefer specifying boot device from command line instead of navigating
bios menus. That what we have to do on real HW because there is not
other way to do it, but in virtualization we can do better.

--
			Gleb.

[Qemu-devel] Re: [SeaBIOS] [RFC] Passing boot order from qemu to seabios

[Avi Kivity]

  On 10/11/2010 05:39 PM, Gleb Natapov wrote:
> On Mon, Oct 11, 2010 at 05:09:22PM +0200, Avi Kivity wrote:
> >   On 10/11/2010 12:18 PM, Gleb Natapov wrote:
> >  >Currently if VM is started with multiple disks it is almost impossible to
> >  >guess which one of them will be used as boot device especially if there
> >  >is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> >  >and without looking into the code you can't tell what the order will
> >  >be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> >  >should allow fine-grained control of boot order from qemu command line,
> >  >or as a minimum control what device will be used for booting.
> >  >
> >  >To do that along with inventing syntax to specify boot order on qemu
> >  >command line we need to communicate boot order to seabios via fw_cfg
> >  >interface. For that we need to have a way to unambiguously specify a
> >  >disk from qemu to seabios.  PCI bus address is not enough since not all
> >  >devices are PCI (do we care about them?) 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)
> >  >
> >  >Will it cover all use cased? Any other ideas? Any ideas about qemu
> >  >command line syntax? May be somebody whats to implement it? :)
> >
> >  Instead of fwcfg, we should store the boot order in the bios.  This
> >  allows seabios to implement persistent boot selection and control
> >  boot order from within the guest.
> >
> It is not "instead of" it is in a best case "in addition too". First of
> all seabios does not have persistent storage currently and second I much
> prefer specifying boot device from command line instead of navigating
> bios menus. That what we have to do on real HW because there is not
> other way to do it, but in virtualization we can do better.

Ok.  So fwcfg will have an option "do your default thing" which the bios 
can take as a hint to look in cmos memory.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [SeaBIOS] [RFC] Passing boot order from qemu to seabios

[Gleb Natapov]

On Mon, Oct 11, 2010 at 05:42:30PM +0200, Avi Kivity wrote:
>  On 10/11/2010 05:39 PM, Gleb Natapov wrote:
> >On Mon, Oct 11, 2010 at 05:09:22PM +0200, Avi Kivity wrote:
> >>   On 10/11/2010 12:18 PM, Gleb Natapov wrote:
> >>  >Currently if VM is started with multiple disks it is almost impossible to
> >>  >guess which one of them will be used as boot device especially if there
> >>  >is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> >>  >and without looking into the code you can't tell what the order will
> >>  >be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> >>  >should allow fine-grained control of boot order from qemu command line,
> >>  >or as a minimum control what device will be used for booting.
> >>  >
> >>  >To do that along with inventing syntax to specify boot order on qemu
> >>  >command line we need to communicate boot order to seabios via fw_cfg
> >>  >interface. For that we need to have a way to unambiguously specify a
> >>  >disk from qemu to seabios.  PCI bus address is not enough since not all
> >>  >devices are PCI (do we care about them?) 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)
> >>  >
> >>  >Will it cover all use cased? Any other ideas? Any ideas about qemu
> >>  >command line syntax? May be somebody whats to implement it? :)
> >>
> >>  Instead of fwcfg, we should store the boot order in the bios.  This
> >>  allows seabios to implement persistent boot selection and control
> >>  boot order from within the guest.
> >>
> >It is not "instead of" it is in a best case "in addition too". First of
> >all seabios does not have persistent storage currently and second I much
> >prefer specifying boot device from command line instead of navigating
> >bios menus. That what we have to do on real HW because there is not
> >other way to do it, but in virtualization we can do better.
> 
> Ok.  So fwcfg will have an option "do your default thing" which the
> bios can take as a hint to look in cmos memory.
> 
Definitely. If qemu does not provide any info about boot order default
logic should be used.

--
			Gleb.

[Qemu-devel] Re: [SeaBIOS] [RFC] Passing boot order from qemu to seabios

[Kevin O'Connor]

On Mon, Oct 11, 2010 at 12:18:55PM +0200, Gleb Natapov wrote:
> Currently if VM is started with multiple disks it is almost impossible to
> guess which one of them will be used as boot device especially if there
> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the order
> and without looking into the code you can't tell what the order will
> be (and in qemu-kvm if boot=on is used it brings even more havoc). We
> should allow fine-grained control of boot order from qemu command line,
> or as a minimum control what device will be used for booting.
> 
> To do that along with inventing syntax to specify boot order on qemu
> command line we need to communicate boot order to seabios via fw_cfg
> interface. For that we need to have a way to unambiguously specify a
> disk from qemu to seabios.  PCI bus address is not enough since not all
> devices are PCI (do we care about them?) 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)

That makes sense to me.

We could update SeaBIOS to give a short unique name to every BEV and
BCV it finds based on the path to the device.  (For example, something
like "ata@01:13.0@0", "usb@1234:5678", "virtio@01:13.0",
"rom@01:13.0".)  Then qemu could pass in (via fw_cfg) a list of names
that the user wishes to boot from.  SeaBIOS can then prioritizes those
devices it finds that are also in the fw_cfg list.

> Will it cover all use cased? Any other ideas? Any ideas about qemu
> command line syntax? May be somebody whats to implement it? :)

As for qemu command line - maybe just use the current ",boot=on"
syntax, and have qemu map it into a "path name" for seabios?

-Kevin