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