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

[Gleb Natapov]

On Mon, Mar 21, 2011 at 02:23:31PM -0700, Jordan Justen wrote:
> 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 :)
No way. Boot process should not require user interaction.

> 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.
non-volatile storage should not be required for OVMF to work. Presence
of non-volatile storage may enable some advanced functionality, but
basic things such as boot should work without. With SeaBIOS we pass many
configuration parameters from VM to BIOS during runtime through firmware
configuration interface. This way we can control things from a host. You
can think of this as if non-volatile storage is managed by VM
management, not VM itself.

> 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.
This sounds reasonable, but how much time will this add to the total boot time?

> 4. Perhaps the VM can signal to the firmware which boot type to use...
How does VM know? And if it does why wouldn't it load legacy bios
directly.

> 
> > 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.
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
/address@hidden/address@hidden/address@hidden/address@hidden
/address@hidden/address@hidden/address@hidden/address@hidden
/address@hidden/address@hidden,1/address@hidden/address@hidden
/address@hidden/address@hidden,1/address@hidden/address@hidden
/address@hidden/address@hidden/address@hidden
/address@hidden/address@hidden/address@hidden
/address@hidden/address@hidden/address@hidden
/address@hidden/address@hidden,1/address@hidden/address@hidden
/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden
/address@hidden/address@hidden,2/address@hidden/address@hidden
/address@hidden/address@hidden,2/address@hidden/address@hidden/address@hidden

OVMF should be able to use that to find boot device.

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

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

--
                        Gleb.