[libvirt] [PATCH 0/4] allow OVMF users to disable qemu's "-boot strict=on"

[Daniel P. Berrange]

On Wed, Jan 22, 2014 at 01:40:26PM +0100, Laszlo Ersek wrote:
> On 01/22/14 12:45, Laine Stump wrote:
> > On 01/22/2014 12:45 PM, Daniel P. Berrange wrote:
> >> On Wed, Jan 22, 2014 at 01:33:18AM +0100, Laszlo Ersek wrote:
> >>> Recently,
> >>>
> >>>   commit 96fddee322c7d39a57cfdc5e7be71326d597d30a
> >>>   Author: Laine Stump <laine at laine.org>
> >>>   Date:   Mon Dec 2 14:07:12 2013 +0200
> >>>
> >>>       qemu: add "-boot strict" to commandline whenever possible
> >>>
> >>> introduced a regression for OVMF guests. The symptoms and causes are
> >>> described in patch 3/4, and in
> >>>
> >>>   https://bugzilla.redhat.com/show_bug.cgi?id=1056258
> >>>
> >>> Let's allow users to opt-out of "-boot strict=on" while preserving it as
> >>> default.
> >> I don't really get from that bug description why this can't be
> >> made to work as desired in OVMF. It seems like its is just a
> >> bug in the OVMF impl that it doesn't work.
> > 
> > I was on the verge of making that same comment in question form. From
> > the information in the patches and the BZ, it sounds like either "--boot
> > strict" is implemented incorrectly for OVMF, or OVMF doesn't do the
> > proper thing with the "HALT".
> > 
> > What does OVMF do with bootable devices that aren't given a specific
> > boot order? For seabios, those devices are all on the boot list
> > following those with specific orders; this is what necessitates --boot
> > strict. The behavior of the option should be consistent regardless of
> > BIOS choice.
> 
> Here's again how OVMF works, in detail.
> 
> First, the list of openfirmware device paths is downloaded from fw_cfg.
> 
> Then they are translated to UEFI device path *prefixes*. This
> translation (even just for the prefixes) is inexact (best effort),
> because no complete mapping exists. Also it can only cover UEFI device
> path prefixes because the OpenFirmware device paths don't extend into
> file paths. In UEFI you can have two separate boot options that boot two
> separate files from the exact same device (including partition), and you
> can't distinguish these in OpenFirmware device paths. Certainly not on
> the qemu command line.
> 
> OK, so now you have two lists, the list of UEFI boot options (pre-set by
> the user in the firmware, or auto-generated by the firmware, doesn't
> matter), and the translated prefix list from qemu/fw_cfg.
> 
> OVMF then iterates over the fw_cfg list, looks up the first prefix match
> from the UEFI boot option list that matches the current translated
> fw_cfg entry. If it is found, then this UEFI boot option is appended to
> the output list, and the UEFI boot option is also marked as having been
> added to the output list
> 
> When the outer loop completes, you have a third list (the output list)
> which describes the user's boot preference. You also have some boot
> options that are unmarked (left unmatched by any translated fw_cfg
> entry). The question is what you do with these.
> 
> Originally, I simply dropped these. This is precisely the -boot
> strict=on behavior. And it was wrong. Users wanted to keep at least
> *some* of these entries at the end of the list. My first question was
> "ok why don't you just specify those in fw_cfg?" And the answer is that
> those options *cannot* be specified.

Ok, so this is the crux of the matter it seems to me.

There are a bunch of boot options which cannot be expressed on
the QEMU command line, or libvirt XML. Users are trying to deal
with this problem by going behind QEMU/libvirt's back and hacking
the firmware image to encode these options.

I place this in the same category as people who replace the QEMU
binary with a shell wrapper script to add a bunch of extra cli
args. ie totally unsupportable.

The goal we have is that the XML description should fully describe
the configuration of a VM. Having a situation where the XML config
only partially describes the setup, and the rest is delegated to
a config embedded in the firmware image is not something we wish
to support.

IMHO what we need to tackle here is the inability to properly
configure the firmware boot order from QEMU / libvirt. ie make
it possible for users to fully control it via libvirt XML.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|