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

[Jordan Justen]

2011/3/22 Gleb Natapov <address@hidden>:
> On Tue, Mar 22, 2011 at 12:28:51PM -0700, Jordan Justen wrote:
>> 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.

It is just a matter of figuring out what to send to the firmware then?

To support a boot override for UEFI, this full path would be needed.
For the purposes of a UEFI boot override, could the user could provide
the partition & path info?

>> (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.

How does this get passed to the firmware?  I'd like to investigate how
to support it in OVMF.

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

I don't know that it matters what you call it (second stage loader?
perhaps...).  One (arguable) issue with legacy boot process is that
some 'magic' code must exist in the MBR.  UEFI has a spec'd image
format, and rather than rely on MBR code, we store a path to the boot
image in a variable.

In UEFI terminology the OS loader is the image pointed at by the boot
variable.  Loading and executing that image is the UEFI equivalent of
loading the MBR and jumping to it.

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

This sounds like a tough to maintain solution.  For boot overrides,
maybe the user can specify the path.

For the non-boot override case, we should add support for
nv-variables, and use the path that the OS sets.

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

Sounds good.  Can you point me at documentation for how this is passed
to the firmware?

Thanks,

-Jordan