[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jordan Justen
Subject: Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot
Date: Tue, 22 Mar 2011 12:28:51 -0700

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

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

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.

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]