The following upstream commit (for bug 1037593) hardwires the '-boot
strict=on' qemu option, if qemu supports it:

  commit e7f2b041a23bcd215549003b52112fff9ddf2306
  Author: Laine Stump <laine>
  Date:   Tue Dec 3 07:45:06 2013 -0700

      qemu: add "-boot strict" to commandline whenever possible

Qemu in turn appends the "HALT" NUL-terminated string to the end of the boot
order fw_cfg file, like this:

  /pci@i0cf8/ethernet@3/ethernet-phy@0
  /pci@i0cf8/scsi@4/disk@0,0
  HALT

HALT is not a valid OpenFirmware device path, and it causes OVMF's parser to
reject the entire boot order specification. This is the direct/immediate
symptom, but the problem is deeper in fact. My reason for asking that this
be fixed in libvirt is a bit long-winded, but please bear with me.

(1) Suppose that I extend OVMF's parser to recognize HALT, terminate the
parsing, and otherwise ignore HALT. This would be incorrect because the user
might expect HALT (ie. -boot strict=on) to work.

(2) Suppose that I extend OVMF's parser to recognize HALT, terminate the
parsing, and honor HALT. Honoring HALT means that the firmware is not
allowed to attempt any other boot options than listed.

This is precisely how the boot option parsing / reordering used to work in
OVMF, until I was asked to modify it. The root cause is that OpenFirmware
device paths are not expressive enough to describe all possible UEFI boot
options (ie. UEFI device paths).

The best we can do in OVMF (which we have been doing since the beginning) is
this:
- rely on the user to set up an initial set of boot options in the firmware
  menu,
- parse boot order specification (OFW paths) from qemu, translate them to
  UEFI device path *prefixes*, and based on the prefix matches, *reorder*
  the existing UEFI boot options.

This works reasonably well (and has been never changed in OVMF). The
question is what should happen to the UEFI boot options that are not matched
at all by the fw_cfg specification.

The initial OVMF approach was *exactly* '-boot strict=on', ie. simply kill
off all options absent from the fw_cfg list, in effect forbidding the
firmware to try to boot any other option. Doing this unconditionally turned
out to be wrong, due to the limited expressive power of qemu's OFW device
paths. A notable example is the memory mapped UEFI shell, which is simply
un-addressible using OFW device paths. Users want to fall back to booting
the shell if other options fail.

Hence, honoring HALT would be possible in OVMF, but it has proved *not* to
be users' default choice. Thus the unconditional libvirt setting is wrong
here; passing HALT assumes that the user *could* specify all his/her choices
if he/she wanted to. This assumption is wrong when the firmware that
consumes the fw_cfg boot spec is OVMF rather than SeaBIOS.

Users need to be informed about this limitation, and informed users should
be given the option to turn off '-boot strict=on'. Please implement it, or
help me implement it. I guess something like:

  <domain>
    <os>
      <boot strict='off'/>
    </os>
  </domain>

would work.

Here's a summary:

Current OVMF behavior (#0):
-boot strict=off -- works as expected
-boot strict=on  -- rejects boot order completely, due to parse error

Possible OVMF behavior #1:
-boot strict=off -- works as expected (no change)
-boot strict=on  -- parses HALT and ignores it (falling back to the UEFI
                    shell even when it was not listed, for example). This
                    lies to the user.

Possible OVMF behavior #2:
-boot strict=off -- works as expected (no change)
-boot strict=on  -- parses HALT and kills everything off the list that has
                    not been specificed; either because the user didn't want
                    to boot from there, or because the user was unable to
                    express his/her desire to boot from there.

It's clear that option #0 is the most honest one (ie. '-boot strict=on'
simply can't be supported in OVMF the way it was invented in QEMU/SeaBIOS).

However, whichever behavior from the three we might want to pick, it's clear
that *unconditionally* selecting '-boot strict=on' is invariably wrong with
OVMF, because "unable to express" cannot be discerned from "not wanting to
boot". Hence please allow '-boot strict=on' to be disabled. Thank you.