Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot

[Gleb Natapov]

On Tue, Mar 22, 2011 at 12:28:51PM -0700, Jordan Justen wrote:
> 2011/3/22 Gleb Natapov <address@hidden>:
> > On Mon, Mar 21, 2011 at 02:23:31PM -0700, Jordan Justen wrote:
> >> There is one big difference here between how VM's generally specify
> >> the boot disk vs. a UEFI system.  In a UEFI system, normally the boot
> >> path is not known during the first boot of the machine.  At some point
> >> the boot path will be programmed into a non-volatile variable.  Often
> >> this will be written by the OS installer.
> > QEMU may pass boot path to UEFI. Qemu encodes it as Open Firmware device
> > path. Examples are:
> > /address@hidden/address@hidden,1/address@hidden/address@hidden
> 
> Can this cover a full path like this?
> /address@hidden/address@hidden,1/address@hidden/address@hidden => partition0 
> => /path/abc.efi
> 
Open Firmware have syntax for that. 
/address@hidden/address@hidden,1/address@hidden/address@hidden:0,/path/abc.efi
But QEMU has no way to know how to specify those additional
parameters. With legacy BIOS each HD has only one boot method.

> >> The point is, normally an 'outside mechanism' like '-boot ?' is not
> >> present.  If the user wants to alter the boot order, they can by
> >> pressing a key during the firmware boot process.
> >>
> >> Also, -boot does map very well to UEFI in a lot of cases.  For
> >> example, boot option 1 in a UEFI system may be something like
> >> /dev/sda1:/efi/boot/ubuntu.efi and option 2 could be
> >> /dev/sda1:/efi/boot/fedora.efi.
> >>
> >> Right now, OVMF doesn't support the qemu -boot parameter...
> >>
> > It should. Otherwise this is a regression from the current behaviour. But
> > the new way to specify boot order is using bootindex not '-boot', so you
> > better support that.
> 
> (Where can I learn more about bootindex?)
It is a device property which is used to set boot priority for a device.
For each device that have this property set QEMU generates device path
and pass it into a firmware along with its boot priority.

> 
> I agree, but the mapping is not 100% right now.  '-boot c' does not
> quite make sense for UEFI, for example.  For floppies or CD's there is
> the concept of a default path: /efi/boot/bootia32.efi or
> /efi/boot/bootx64.efi, but this doesn't apply to hard disks, and you
> need to know the path to the image to load off that hard disk.
Looks like UEFI tries to be second stage boot loader too. Given device
path that points to HD can OVMF scan it for common locations where OSes
usually install .efi files and boot the first one it finds?

> 
> Also, could QEMU support one mode where the boot device is specified,
> and the firmware would know that an override was provided for the boot
> path, and another mode where it is not specified, and we can look at
> the boot variables?
> 
That what QEMU does today. It either supplies boot order information or
leaves it to firmware to decide where to boot from, or tells firmware to
present user with boot menu.

--
                        Gleb.