Bug 1056258 - [RFE] qemu driver: please add knob to disable '-boot strict=on'
[RFE] qemu driver: please add knob to disable '-boot strict=on'
Status: CLOSED NOTABUG
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Laszlo Ersek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-21 14:11 EST by Laszlo Ersek
Modified: 2014-01-28 13:04 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-28 13:04:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Laszlo Ersek 2014-01-21 14:11:36 EST
The following upstream commit (for bug 1037593) hardwires the '-boot
strict=on' qemu option, if qemu supports it:

  commit e7f2b041a23bcd215549003b52112fff9ddf2306
  Author: Laine Stump <laine@laine.org>
  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.
Comment 1 Laszlo Ersek 2014-01-21 17:36:46 EST
(In reply to Laszlo Ersek from comment #0)
> The following upstream commit (for bug 1037593) hardwires the '-boot
> strict=on' qemu option, if qemu supports it:
> 
>   commit e7f2b041a23bcd215549003b52112fff9ddf2306
>   Author: Laine Stump <laine@laine.org>
>   Date:   Tue Dec 3 07:45:06 2013 -0700
> 
>       qemu: add "-boot strict" to commandline whenever possible

aaaargh, that's a RHEL commit hash. Upstream is 96fddee3.
Comment 2 Laszlo Ersek 2014-01-21 19:34:35 EST
Posted upsteam series:
http://www.redhat.com/archives/libvir-list/2014-January/msg00971.html
Comment 3 Laszlo Ersek 2014-01-28 13:04:29 EST
Based on the libvir-list discussion, I'm addressing the situation in OVMF instead.

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/6065

Note You need to log in before you can comment on or make changes to this bug.