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