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

[Jordan Justen]

On Mon, Mar 21, 2011 at 11:27, Anthony Liguori <address@hidden> wrote:
> On 03/21/2011 01:14 PM, Jordan Justen wrote:
>>
>> This weekend I spent some time working on loading SeaBIOS from OVMF to
>> start a legacy boot.  I was able to get x86&  x86-64 Linux to legacy
>> boot using this method.
>>
>> Unfortunately, (I think) it is not nearly as nice a having a true CSM.
>>  Basically, you have to decide at some point in the OVMF boot that you
>> want to legacy boot, and once you start SeaBIOS running, OVMF/UEFI
>
> Interesting.  How much time does OVMF add to the total boot time when taking
> this approach?

SeaBIOS has OVMF beat hands-down for boot time at this point.  (For
what it's worth, I have not focused on boot time for OVMF at all.)  It
is several seconds for OVMF, vs. lightning-fast for SeaBIOS. :)

This approach is essentially OVMF booting for a bit, and then forking
off to load SeaBIOS at some point.  So, we could make it take very
little extra time if we were able to determine very early in the OVMF
boot that this is the boot type that we wanted.

At this point, I'm not sure how it could be determined.  Some ideas
(none great):
1. Let the user press a hotkey such as 'u' for UEFI, and thus wait ~ 1
second for the key.  (Yuck :)
2. Push UEFI variable support forward.  During the first boot
determine if a legacy boot is needed, and save a variable that can be
accessed early on to trigger SeaBIOS loading very quickly for future
boots.
3. Always boot mostly through the OVMF boot sequence, and if we don't
see a GPT formatted disk or a UEFI bootable removable media, then run
SeaBIOS.
4. Perhaps the VM can signal to the firmware which boot type to use...

> Is there gPXE for UEFI yet?

I don't know too much about network boot for UEFI, but I know there is
UEFI PXE support.  I'm not familar with gPXE.

> Other than that, this probably matters most of with device passthrough.  I
> think this is a limitation we could live with in the not-to-short term
> though.
>
>> * Fail a legacy boot, and potentially return back to UEFI if it fails.
>>   (Not in all cases, if the failed boot alters the system state
>> significantly)
>
> I think the most typical use-case here is -boot cd or -boot dc.  From what I
> can tell, EFI support El Torito so it wouldn't be necessary to involve BIOS
> to handle booting from CDROMs.  Is that correct?

If there is any sort of legacy boot, then either we'd need to boot
SeaBIOS or have CSM support.  If it is a UEFI boot, then El Torito is
used so a disk image is available with a UEFI boot loader present.

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.

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

>> So, would this be valuable (in the short term) to help move forward
>> QEMU's usage of OVMF and add UEFI support?  Or would QEMU require true
>> CSM support?
>
> I think this certainly helps make the discussion more concrete.  I don't see
> any show stoppers here.

Ok, it sounds like it could be a useful path to consider, given the
lack of a CSM.  I'll continue to look at it some more...

Thanks,

-Jordan