[SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios
gleb at redhat.com
Mon Oct 11 23:14:05 CEST 2010
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
> 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.
More information about the SeaBIOS