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

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

[Jordan Justen]

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
will never be in the picture again (until system reset).

Contrast this to using a CSM where you can:
* Load a legacy option ROM (vbios, or disk rom),
  and use it during a UEFI boot
* 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)
* Specify via UEFI the boot process which disk to legacy boot in the CSM

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?

Thanks,

-Jordan

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

[Anthony Liguori]

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?

> will never be in the picture again (until system reset).
>
> Contrast this to using a CSM where you can:
> * Load a legacy option ROM (vbios, or disk rom),
>    and use it during a UEFI boot

Is there gPXE for UEFI yet?

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?

> * Specify via UEFI the boot process which disk to legacy boot in the CSM

I'm sure this is workable.

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

Regards,

Anthony Liguori

> Thanks,
>
> -Jordan
>

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

[Stefan Hajnoczi]

On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori <anthony@codemonkey.ws> 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?
>
>> will never be in the picture again (until system reset).
>>
>> Contrast this to using a CSM where you can:
>> * Load a legacy option ROM (vbios, or disk rom),
>>   and use it during a UEFI boot
>
> Is there gPXE for UEFI yet?

I have never tried it myself, but I think it should work.  CCed
Michael Brown to check.

Stefan

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

[Michael Brown]

On Monday 21 Mar 2011 21:06:24 Stefan Hajnoczi wrote:
> On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori <anthony@codemonkey.ws> 
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?
> >
> >> will never be in the picture again (until system reset).
> >>
> >> Contrast this to using a CSM where you can:
> >> * Load a legacy option ROM (vbios, or disk rom),
> >>   and use it during a UEFI boot
> >
> > Is there gPXE for UEFI yet?
> 
> I have never tried it myself, but I think it should work.  CCed
> Michael Brown to check.

Yes, iPXE for UEFI exists and works.  Last tested by me about a week ago, on 
various IBM UEFI systems.

Compared to a "legacy" BIOS network boot, you can't do anything very 
interesting with UEFI.  Features such as iSCSI, FCoE, AoE, HTTP all work with 
a "legacy" BIOS but not with UEFI.  A "legacy" BIOS network boot allows you to 
boot an operating system; a UEFI network boot only allows you to boot an EFI 
executable (which could be a second-stage OS loader).

UEFI as a platform has a long way to go before it matches the network boot 
functionality available through iPXE in a "legacy" BIOS.

Michael

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

[Jordan Justen]

On Mon, Mar 21, 2011 at 11:27, Anthony Liguori <anthony@codemonkey.ws> 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

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

[Jordan Justen]

On Mon, Mar 21, 2011 at 14:17, Michael Brown <mbrown@fensystems.co.uk> wrote:
> On Monday 21 Mar 2011 21:06:24 Stefan Hajnoczi wrote:
>> On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori <anthony@codemonkey.ws>
>> > Is there gPXE for UEFI yet?
>>
>> I have never tried it myself, but I think it should work.  CCed
>> Michael Brown to check.
>
> Yes, iPXE for UEFI exists and works.  Last tested by me about a week ago, on
> various IBM UEFI systems.
>
> Compared to a "legacy" BIOS network boot, you can't do anything very
> interesting with UEFI.  Features such as iSCSI, FCoE, AoE, HTTP all work with
> a "legacy" BIOS but not with UEFI.  A "legacy" BIOS network boot allows you to
> boot an operating system; a UEFI network boot only allows you to boot an EFI
> executable (which could be a second-stage OS loader).

Your input on network boot is much more valuable than mine.  (I'm
certainly no expert here...)

But, for a UEFI system, loading a UEFI executable is equivalent to
starting the OS.  Whether that executable is a second stage loader, or
contains the OS kernel, it up to the OS implementation.

-Jordan

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

[Stefan Hajnoczi]

On Mon, Mar 21, 2011 at 9:17 PM, Michael Brown <mbrown@fensystems.co.uk> wrote:
> On Monday 21 Mar 2011 21:06:24 Stefan Hajnoczi wrote:
>> On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori <anthony@codemonkey.ws>
> 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?
>> >
>> >> will never be in the picture again (until system reset).
>> >>
>> >> Contrast this to using a CSM where you can:
>> >> * Load a legacy option ROM (vbios, or disk rom),
>> >>   and use it during a UEFI boot
>> >
>> > Is there gPXE for UEFI yet?
>>
>> I have never tried it myself, but I think it should work.  CCed
>> Michael Brown to check.
>
> Yes, iPXE for UEFI exists and works.  Last tested by me about a week ago, on
> various IBM UEFI systems.
>
> Compared to a "legacy" BIOS network boot, you can't do anything very
> interesting with UEFI.  Features such as iSCSI, FCoE, AoE, HTTP all work with
> a "legacy" BIOS but not with UEFI.  A "legacy" BIOS network boot allows you to
> boot an operating system; a UEFI network boot only allows you to boot an EFI
> executable (which could be a second-stage OS loader).

Would it be possible to enable the more interesting things by
registering as a network device or block device with UEFI?  I don't
know much about UEFI but I seem to remember that you can do that
rather than being a pure bootloader that loads an EFI executable?

Stefan

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

[Michael Brown]

On Monday 21 Mar 2011 21:40:31 Stefan Hajnoczi wrote:
> > Yes, iPXE for UEFI exists and works.  Last tested by me about a week ago,
> > on various IBM UEFI systems.
> >
> > Compared to a "legacy" BIOS network boot, you can't do anything very
> > interesting with UEFI.  Features such as iSCSI, FCoE, AoE, HTTP all work
> > with a "legacy" BIOS but not with UEFI.  A "legacy" BIOS network boot
> > allows you to boot an operating system; a UEFI network boot only allows
> > you to boot an EFI executable (which could be a second-stage OS loader).
> 
> Would it be possible to enable the more interesting things by
> registering as a network device or block device with UEFI?  I don't
> know much about UEFI but I seem to remember that you can do that
> rather than being a pure bootloader that loads an EFI executable?

Yes, and that's what we already do.  Third-party products can, in theory at 
least, use the SNP device provided by an iPXE driver to communicate over the 
network via any protocol that the third-party product wants to implement.

What I meant is that the iSCSI, FCoE, Infiniband, etc. functionality that is 
built in to iPXE and available to a "legacy" BIOS cannot be exposed under 
UEFI.  You need a third-party product which in some cases (e.g. for HTTP boot 
or to use an Infiniband HCA) may not yet exist.

I'm actually quite looking forward to finding a practical use case for UEFI.  
All instances that I've seen so far involve nothing more than adding 
approximately five _minutes_ of initial boot delay before dropping into the 
"legacy" boot environment.

Michael

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 <anthony@codemonkey.ws> 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:
/pci@i0cf8/ide@1,1/drive@1/disk@0
/pci@i0cf8/isa@1/fdc@03f1/floppy@1
/pci@i0cf8/isa@1/fdc@03f1/floppy@0
/pci@i0cf8/ide@1,1/drive@1/disk@1
/pci@i0cf8/ide@1,1/drive@0/disk@0
/pci@i0cf8/scsi@3/disk@0
/pci@i0cf8/ethernet@4/ethernet-phy@0
/pci@i0cf8/ethernet@5/ethernet-phy@0
/pci@i0cf8/ide@1,1/drive@0/disk@1
/pci@i0cf8/isa@1/ide@01e8/drive@0/disk@0
/pci@i0cf8/usb@1,2/network@0/ethernet@0
/pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0

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.

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

[Jordan Justen]

2011/3/22 Gleb Natapov <gleb@redhat.com>:
> 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:
> /pci@i0cf8/ide@1,1/drive@1/disk@0

Can this cover a full path like this?
/pci@i0cf8/ide@1,1/drive@1/disk@0 => partition0 => /path/abc.efi

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

Thanks,

-Jordan

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 <gleb@redhat.com>:
> > 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:
> > /pci@i0cf8/ide@1,1/drive@1/disk@0
> 
> Can this cover a full path like this?
> /pci@i0cf8/ide@1,1/drive@1/disk@0 => partition0 => /path/abc.efi
> 
Open Firmware have syntax for that. /pci@i0cf8/ide@1,1/drive@1/disk@0: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.

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

[Jordan Justen]

2011/3/22 Gleb Natapov <gleb@redhat.com>:
> On Tue, Mar 22, 2011 at 12:28:51PM -0700, Jordan Justen wrote:
>> Can this cover a full path like this?
>> /pci@i0cf8/ide@1,1/drive@1/disk@0 => partition0 => /path/abc.efi
>>
> Open Firmware have syntax for that. /pci@i0cf8/ide@1,1/drive@1/disk@0: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

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

[Gleb Natapov]

On Tue, Mar 22, 2011 at 02:53:16PM -0700, Jordan Justen wrote:
> 2011/3/22 Gleb Natapov <gleb@redhat.com>:
> > On Tue, Mar 22, 2011 at 12:28:51PM -0700, Jordan Justen wrote:
> >> Can this cover a full path like this?
> >> /pci@i0cf8/ide@1,1/drive@1/disk@0 => partition0 => /path/abc.efi
> >>
> > Open Firmware have syntax for that. /pci@i0cf8/ide@1,1/drive@1/disk@0: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?
> 
Well yes. But it is not as easy as it sounds.

> 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?
> 
How the user knows what to provide. In most cases this user will be
management anyway. So the use case is like this: new HD is connected
to a VM and user wants to boot whatever is installed there. With legacy
boot this is the matter of running MBR code, with UEFI user need to boot
something else and browse file system hierarchy to find magic file to
boot from? Sound like step backward even from legacy bios :) Is the some
notion of default boot in UEFI.

> >> (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.
> 
It is passed using simple ISA device. Look at src/paravirt.c in Seabios source code.
The device emulation itself is in hw/fw_cfg.c in QEMU source tree.

> >> 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. 
Legacy boot process has many issues but I wouldn't call MBR one of them.
But lest not argue about that. I doubt we will be able to change UEFI now :)

>                                           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.
With legacy boot, given hard drive firmware knows how to boot from it.
HD is self contained. No need "out of band" channel to inform firmware
how to boot from the HD.

> 
> 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.
> 
So no much difference except that MBR is actually better because it is
in the knows location? Why not store default boot path in MBR if it is
unused now anyway (we have no much space there, but should be enough for
reasonable paths)?

> > 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.
User shouldn't know or care. He should be able to download raw disk
image from internet and run it with "qemu -hda image.raw" and boot into
whatever installed there if the image is bootable. It sounds like UEFI
can't support such usage scenario! And I am not even talk about boot
overrides in the above scenario.

> 
> For the non-boot override case, we should add support for
> nv-variables, and use the path that the OS sets.
That makes VM usage much less flexible then it is today. Disk images are
not self contained any more. I have tens of images that I run inside
different VMs from different hosts all of the time. It is unreasonable
to expect that I will track additional images with nv-variables needed
to boot from them.

> 
> >> 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?
> 
No documentation, but it is very simple interface. See source code I
pointed to above. Ah and bootindex actually has a little bit of
documentation in qemu/docs/bootindex.txt

--
			Gleb.

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

[Jordan Justen]

2011/3/23 Gleb Natapov <gleb@redhat.com>:
> On Tue, Mar 22, 2011 at 02:53:16PM -0700, Jordan Justen wrote:
>> 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?
>>
> How the user knows what to provide. In most cases this user will be
> management anyway. So the use case is like this: new HD is connected
> to a VM and user wants to boot whatever is installed there.

Yeah, that sounds like something something you or I might do, but not
your average user.

But, a VM user is most likely not your average user I guess. :)

> With legacy
> boot this is the matter of running MBR code, with UEFI user need to boot
> something else and browse file system hierarchy to find magic file to
> boot from?
> Sound like step backward even from legacy bios :)

True, it is not a great scenario.

But you can set up the boot options by browsing the filesystems in the
firmware setup program.

> Is the some notion of default boot in UEFI.

Only for removable media (CD, floppy, USB).  In that case
/efi/boot/boot(ia32|x64).efi can be 'searched' for.

I don't think any UEFI OS installs it's OS loader on the hard disk at this path.

>> 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.
> Legacy boot process has many issues but I wouldn't call MBR one of them.

Tell that to my current system which I foolishly partitioned with GPT,
and can't get grub/grub2 to work with. :)

> But lest not argue about that. I doubt we will be able to change UEFI now :)

Yes, many things are frustratingly solidified in UEFI at this point.
Some spec related, some install base related.

>> This sounds like a tough to maintain solution.  For boot overrides,
>> maybe the user can specify the path.
> User shouldn't know or care. He should be able to download raw disk
> image from internet and run it with "qemu -hda image.raw" and boot into
> whatever installed there if the image is bootable. It sounds like UEFI
> can't support such usage scenario! And I am not even talk about boot
> overrides in the above scenario.

Yes, I can't think of a great 'user-friendly' solution to this, except
for the VM to crack the fs and scan for boot loaders.  It might have
'known' ones, or ask the user.  And this would only make sense for
importing a disk image in a GUI.

Importing VM's via a GUI these days often involves a lot more metadata
than just a disk image, so that might be able to include the NV-Vars
data.

>> For the non-boot override case, we should add support for
>> nv-variables, and use the path that the OS sets.
> That makes VM usage much less flexible then it is today. Disk images are
> not self contained any more. I have tens of images that I run inside
> different VMs from different hosts all of the time. It is unreasonable
> to expect that I will track additional images with nv-variables needed
> to boot from them.

Hmm, I'm not sure what to say.  I guess you'd need to know your path, ie:
/pci@i0cf8/ide@1,1/drive@1/disk@0:0,/path/abc.efi
associated with each disk image.

By the way, today OVMF attempts to store NV-Var data in a file on the
disk, but this cannot support variables at runtime.  (This is why I
sent in the patch for using -pflash on x86/x86-64.)

Thanks,

-Jordan

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

[Gleb Natapov]

On Wed, Mar 23, 2011 at 03:32:41PM -0700, Jordan Justen wrote:
> 2011/3/23 Gleb Natapov <gleb@redhat.com>:
> > On Tue, Mar 22, 2011 at 02:53:16PM -0700, Jordan Justen wrote:
> >> 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?
> >>
> > How the user knows what to provide. In most cases this user will be
> > management anyway. So the use case is like this: new HD is connected
> > to a VM and user wants to boot whatever is installed there.
> 
> Yeah, that sounds like something something you or I might do, but not
> your average user.
> 
I don't see any advanced use case here.

> But, a VM user is most likely not your average user I guess. :)
Management apps (such as libvirt) are VM users too and they may do
pretty advanced things. For instance create VM from preinstalled image.
Actually this is very common use case when VM is provisioned from
preinstalled disk template. 

> 
> > With legacy
> > boot this is the matter of running MBR code, with UEFI user need to boot
> > something else and browse file system hierarchy to find magic file to
> > boot from?
> > Sound like step backward even from legacy bios :)
> 
> True, it is not a great scenario.
> 
> But you can set up the boot options by browsing the filesystems in the
> firmware setup program.
> 
For that I need to involve VM user. Not acceptable. OVMF should find
what to boot for him. User can't be trusted to handle such complex task.
Actually VM may never have a user in the common sense of the word:
person that sits against monitor and operate this particular guest.
May be store the path on a disk in a hidden partition somewhere?

> > Is the some notion of default boot in UEFI.
> 
> Only for removable media (CD, floppy, USB).  In that case
> /efi/boot/boot(ia32|x64).efi can be 'searched' for.
> 
That's good. So we have problems only with hard disks.

> I don't think any UEFI OS installs it's OS loader on the hard disk at this path.
> 
How UEFI OS tells UEFI firmware where to boot from?

> >> 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.
> > Legacy boot process has many issues but I wouldn't call MBR one of them.
> 
> Tell that to my current system which I foolishly partitioned with GPT,
> and can't get grub/grub2 to work with. :)
> 
That's grub/grub2 problem, no? Does grub support EFI at all?

> > But lest not argue about that. I doubt we will be able to change UEFI now :)
> 
> Yes, many things are frustratingly solidified in UEFI at this point.
> Some spec related, some install base related.
> 
> >> This sounds like a tough to maintain solution.  For boot overrides,
> >> maybe the user can specify the path.
> > User shouldn't know or care. He should be able to download raw disk
> > image from internet and run it with "qemu -hda image.raw" and boot into
> > whatever installed there if the image is bootable. It sounds like UEFI
> > can't support such usage scenario! And I am not even talk about boot
> > overrides in the above scenario.
> 
> Yes, I can't think of a great 'user-friendly' solution to this, except
> for the VM to crack the fs and scan for boot loaders.  It might have
> 'known' ones, or ask the user.  And this would only make sense for
> importing a disk image in a GUI.
> 
> Importing VM's via a GUI these days often involves a lot more metadata
> than just a disk image, so that might be able to include the NV-Vars
> data.
> 
Any direct invocation of qemu from command line can be thought of as
"importing a disk image". This may be considered as advance use case,
but I think we still have to make it as usable as it is now.

For non-raw disk formats like qcow2 we may save path to boot image
somewhere in image metadata and provide interface to set it from a
guest, but for raw format this will not work.

> >> For the non-boot override case, we should add support for
> >> nv-variables, and use the path that the OS sets.
> > That makes VM usage much less flexible then it is today. Disk images are
> > not self contained any more. I have tens of images that I run inside
> > different VMs from different hosts all of the time. It is unreasonable
> > to expect that I will track additional images with nv-variables needed
> > to boot from them.
> 
> Hmm, I'm not sure what to say.  I guess you'd need to know your path, ie:
> /pci@i0cf8/ide@1,1/drive@1/disk@0:0,/path/abc.efi
> associated with each disk image.
> 
I need to know only 0,/path/abc.efi part of it. The same image can
appear as different device depending on how VM was started. We need
to find the place to store this info at the image itself.

> By the way, today OVMF attempts to store NV-Var data in a file on the
> disk, but this cannot support variables at runtime.  (This is why I
> sent in the patch for using -pflash on x86/x86-64.)
> 
And this file is stored always at the same location? If it is then then
problem is solved! But what do you mean by "this cannot support
variables at runtime"?

--
			Gleb.

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

[Michal Suchanek]

On 23 March 2011 23:32, Jordan Justen <jljusten@gmail.com> wrote:
> 2011/3/23 Gleb Natapov <gleb@redhat.com>:
>> On Tue, Mar 22, 2011 at 02:53:16PM -0700, Jordan Justen wrote:
>>> 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?
>>>
>> How the user knows what to provide. In most cases this user will be
>> management anyway. So the use case is like this: new HD is connected
>> to a VM and user wants to boot whatever is installed there.
>
> Yeah, that sounds like something something you or I might do, but not
> your average user.
>
> But, a VM user is most likely not your average user I guess. :)
>
>> With legacy
>> boot this is the matter of running MBR code, with UEFI user need to boot
>> something else and browse file system hierarchy to find magic file to
>> boot from?
>> Sound like step backward even from legacy bios :)
>
> True, it is not a great scenario.
>
> But you can set up the boot options by browsing the filesystems in the
> firmware setup program.
>
>> Is the some notion of default boot in UEFI.
>
> Only for removable media (CD, floppy, USB).  In that case
> /efi/boot/boot(ia32|x64).efi can be 'searched' for.
>

To the contrary.

The distinction between removable and fixed media is quite blurry these days.

Is an eSATA disk removable? Or a SATA disk connected to AHCI
controller through an internal (but hotplug capable) connector?
And when I unplug the disk, put it into an enclosure and connect
through USB has it magically started to be removable then?

When installing EFI bootloaders it is suggested to create a small FAT
partition at the start of the disk and put the loader there, just
under this name.

The Apple EFI also understands some variables stored in their HFS
volumes but that's another story.

If you want to prepare a disk image for somebody to use you *can* put
the bootloader in the well-known location.

If you pass just the raw disk image to somebody else it is technically
removable and should use the removable path, and the user can attach
it through the USB emulation if they insist on making it clearly
removable.

Thanks

Michal

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

[Gleb Natapov]

On Thu, Mar 24, 2011 at 01:27:39PM +0100, Michal Suchanek wrote:
> On 23 March 2011 23:32, Jordan Justen <jljusten@gmail.com> wrote:
> > 2011/3/23 Gleb Natapov <gleb@redhat.com>:
> >> On Tue, Mar 22, 2011 at 02:53:16PM -0700, Jordan Justen wrote:
> >>> 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?
> >>>
> >> How the user knows what to provide. In most cases this user will be
> >> management anyway. So the use case is like this: new HD is connected
> >> to a VM and user wants to boot whatever is installed there.
> >
> > Yeah, that sounds like something something you or I might do, but not
> > your average user.
> >
> > But, a VM user is most likely not your average user I guess. :)
> >
> >> With legacy
> >> boot this is the matter of running MBR code, with UEFI user need to boot
> >> something else and browse file system hierarchy to find magic file to
> >> boot from?
> >> Sound like step backward even from legacy bios :)
> >
> > True, it is not a great scenario.
> >
> > But you can set up the boot options by browsing the filesystems in the
> > firmware setup program.
> >
> >> Is the some notion of default boot in UEFI.
> >
> > Only for removable media (CD, floppy, USB).  In that case
> > /efi/boot/boot(ia32|x64).efi can be 'searched' for.
> >
> 
> To the contrary.
> 
> The distinction between removable and fixed media is quite blurry these days.
> 
My thoughts exactly. It is double blurry in virtualization world where
moving any media from VM to VM is so easy.

> Is an eSATA disk removable? Or a SATA disk connected to AHCI
> controller through an internal (but hotplug capable) connector?
> And when I unplug the disk, put it into an enclosure and connect
> through USB has it magically started to be removable then?
> 
> When installing EFI bootloaders it is suggested to create a small FAT
> partition at the start of the disk and put the loader there, just
> under this name.
> 
> The Apple EFI also understands some variables stored in their HFS
> volumes but that's another story.
> 
> If you want to prepare a disk image for somebody to use you *can* put
> the bootloader in the well-known location.
> 
> If you pass just the raw disk image to somebody else it is technically
> removable and should use the removable path, and the user can attach
> it through the USB emulation if they insist on making it clearly
> removable.
> 
> Thanks
> 
> Michal

--
			Gleb.

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

[Jordan Justen]

2011/3/24 Gleb Natapov <gleb@redhat.com>:
> On Wed, Mar 23, 2011 at 03:32:41PM -0700, Jordan Justen wrote:
>> By the way, today OVMF attempts to store NV-Var data in a file on the
>> disk, but this cannot support variables at runtime.  (This is why I
>> sent in the patch for using -pflash on x86/x86-64.)
>>
> And this file is stored always at the same location? If it is then then
> problem is solved! But what do you mean by "this cannot support
> variables at runtime"?

The variables can be set while the OS is running, and the OS has
exclusive control over the disk at that time.  Today in OVMF we set
variables into memory during this time, and hope that memory it still
around after a reset.  This does not provide realistic non-volatile
UEFI variable support.

What we really need is flash memory.  (See my 'hw/pc: Support system
flash memory' patch.)

But, there is nothing stopping us from also storing the variables on
the disk (during the firmware boot), and also using them as a backup.

Additionally, we can add yet another backup system of looking for
known os-loader executable paths.  This would be needed if a disk
image were ever to be transferred from a real machine to a VM image.
But, this would require firmware updates as new UEFI OS loader install
paths are added.  Also, let's hope no OS decides to generate a random
path for the OS loader. :)

-Jordan

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

[Gleb Natapov]

On Thu, Mar 24, 2011 at 09:46:09AM -0700, Jordan Justen wrote:
> 2011/3/24 Gleb Natapov <gleb@redhat.com>:
> > On Wed, Mar 23, 2011 at 03:32:41PM -0700, Jordan Justen wrote:
> >> By the way, today OVMF attempts to store NV-Var data in a file on the
> >> disk, but this cannot support variables at runtime.  (This is why I
> >> sent in the patch for using -pflash on x86/x86-64.)
> >>
> > And this file is stored always at the same location? If it is then then
> > problem is solved! But what do you mean by "this cannot support
> > variables at runtime"?
> 
> The variables can be set while the OS is running, and the OS has
> exclusive control over the disk at that time.  Today in OVMF we set
> variables into memory during this time, and hope that memory it still
> around after a reset.  This does not provide realistic non-volatile
> UEFI variable support.
KVM preserve memory during reset, but we better not rely on that.

> 
> What we really need is flash memory.  (See my 'hw/pc: Support system
> flash memory' patch.)
Storing boot file only on flash memory will require to distribute the
flash image along with disk image.

> 
> But, there is nothing stopping us from also storing the variables on
> the disk (during the firmware boot), and also using them as a backup.
> 
This will still require at least one reboot for variables to be saved in
a filesystem, but this is better then nothing.

> Additionally, we can add yet another backup system of looking for
> known os-loader executable paths.  This would be needed if a disk
> image were ever to be transferred from a real machine to a VM image.
> But, this would require firmware updates as new UEFI OS loader install
> paths are added.  Also, let's hope no OS decides to generate a random
> path for the OS loader. :)
> 
Firmware updates in a VM is very easy, so not a big deal.

--
			Gleb.