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

[Jordan Justen]

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.

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