[libvirt] [PATCH 0/4] allow OVMF users to disable qemu's "-boot strict=on"
Recently, commit 96fddee322c7d39a57cfdc5e7be71326d597d30a Author: Laine Stump <laine@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. Please review. Thanks, Laszlo Laszlo Ersek (4): domain: introduce os.bootStrict domain: parse and format os.bootStrict from/to XML qemu: parse and format os.bootStrict from/to command line parallels: reject non-default os.bootStrict src/conf/domain_conf.h | 11 ++++ src/conf/domain_conf.c | 26 +++++++++ src/parallels/parallels_driver.c | 1 + src/qemu/qemu_command.c | 17 +++++- tests/qemuxml2argvtest.c | 4 ++ docs/formatdomain.html.in | 9 +++ docs/schemas/domaincommon.rng | 10 ++++ src/libvirt_private.syms | 2 + tests/qemuxml2argvdata/qemuxml2argv-boot-cdrom.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-boot-floppy.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-boot-network.xml | 1 + .../qemuxml2argv-boot-strict-off.args | 36 ++++++++++++ .../qemuxml2argv-boot-strict-off.xml | 67 ++++++++++++++++++++++ .../qemuxml2argv-clock-localtime.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-clock-utc.xml | 1 + .../qemuxml2argv-console-compat.xml | 1 + .../qemuxml2argv-disk-cdrom-empty.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom.xml | 1 + .../qemuxml2argv-disk-drive-boot-cdrom.xml | 1 + .../qemuxml2argv-disk-drive-boot-disk.xml | 1 + .../qemuxml2argv-disk-drive-cache-directsync.xml | 1 + .../qemuxml2argv-disk-drive-cache-unsafe.xml | 1 + .../qemuxml2argv-disk-drive-cache-v1-none.xml | 1 + .../qemuxml2argv-disk-drive-cache-v1-wb.xml | 1 + .../qemuxml2argv-disk-drive-cache-v2-none.xml | 1 + .../qemuxml2argv-disk-drive-cache-v2-wb.xml | 1 + .../qemuxml2argv-disk-drive-cache-v2-wt.xml | 1 + ...muxml2argv-disk-drive-error-policy-enospace.xml | 1 + .../qemuxml2argv-disk-drive-error-policy-stop.xml | 1 + ...rgv-disk-drive-error-policy-wreport-rignore.xml | 1 + .../qemuxml2argv-disk-drive-fmt-qcow.xml | 1 + .../qemuxml2argv-disk-drive-network-gluster.xml | 1 + .../qemuxml2argv-disk-drive-network-iscsi.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd-export.xml | 1 + ...xml2argv-disk-drive-network-nbd-ipv6-export.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd-ipv6.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd-unix.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd.xml | 1 + ...emuxml2argv-disk-drive-network-rbd-ceph-env.xml | 1 + .../qemuxml2argv-disk-drive-network-rbd-ipv6.xml | 1 + .../qemuxml2argv-disk-drive-network-rbd.xml | 1 + .../qemuxml2argv-disk-drive-network-sheepdog.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-disk-floppy.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-disk-many.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-disk-usb.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-disk-virtio.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-disk-xenvbd.xml | 1 + .../qemuxml2argv-graphics-sdl-fullscreen.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-graphics-sdl.xml | 1 + .../qemuxml2argv-graphics-vnc-policy.xml | 1 + .../qemuxml2argv-graphics-vnc-sasl.xml | 1 + .../qemuxml2argv-graphics-vnc-socket.xml | 1 + .../qemuxml2argv-graphics-vnc-tls.xml | 1 + .../qemuxml2argv-graphics-vnc-websocket.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-graphics-vnc.xml | 1 + .../qemuxml2argv-hostdev-pci-address.xml | 1 + .../qemuxml2argv-hostdev-usb-address.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-hyperv.xml | 1 + .../qemuxml2argv-input-usbmouse.xml | 1 + .../qemuxml2argv-input-usbtablet.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-kvmclock.xml | 1 + .../qemuxml2argv-machine-core-off.xml | 1 + .../qemuxml2argv-machine-core-on.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-migrate.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-misc-acpi.xml | 1 + .../qemuxml2argv-misc-disable-s3.xml | 1 + .../qemuxml2argv-misc-disable-suspends.xml | 1 + .../qemuxml2argv-misc-enable-s4.xml | 1 + .../qemuxml2argv-misc-no-reboot.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml | 1 + .../qemuxml2argv-net-eth-ifname.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-net-eth.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-net-user.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-net-virtio.xml | 1 + .../qemuxml2argv-nographics-vga.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-nosharepages.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-parallel-tcp.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-pseries-disk.xml | 1 + .../qemuxml2argv-pseries-nvram.xml | 1 + .../qemuxml2argv-qemu-ns-no-env.xml | 1 + .../qemuxml2argv-reboot-timeout-disabled.xml | 1 + .../qemuxml2argv-reboot-timeout-enabled.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-restore-v1.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-restore-v2.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-dev.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-serial-file.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-serial-many.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-pty.xml | 1 + .../qemuxml2argv-serial-tcp-telnet.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-tcp.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-serial-unix.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-vc.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-smp.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-sound.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-watchdog.xml | 1 + 96 files changed, 268 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.xml -- 1.8.3.1
This field will allow the user to disable strict booting under qemu. Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- src/conf/domain_conf.h | 11 +++++++++++ src/conf/domain_conf.c | 5 +++++ src/libvirt_private.syms | 2 ++ 3 files changed, 18 insertions(+) diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index d8f2e49..3b1bf7d 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1633,6 +1633,14 @@ enum virDomainBootMenu { VIR_DOMAIN_BOOT_MENU_LAST }; +enum virDomainBootStrict { + VIR_DOMAIN_BOOT_STRICT_DEFAULT = 0, + VIR_DOMAIN_BOOT_STRICT_ENABLED, + VIR_DOMAIN_BOOT_STRICT_DISABLED, + + VIR_DOMAIN_BOOT_STRICT_LAST +}; + enum virDomainFeature { VIR_DOMAIN_FEATURE_ACPI, VIR_DOMAIN_FEATURE_APIC, @@ -1728,6 +1736,8 @@ struct _virDomainOSDef { int bootDevs[VIR_DOMAIN_BOOT_LAST]; /* enum virDomainBootMenu */ int bootmenu; + /* enum virDomainBootStrict */ + int bootStrict; char *init; char **initargv; char *kernel; @@ -2643,6 +2653,7 @@ VIR_ENUM_DECL(virDomainTaint) VIR_ENUM_DECL(virDomainVirt) VIR_ENUM_DECL(virDomainBoot) VIR_ENUM_DECL(virDomainBootMenu) +VIR_ENUM_DECL(virDomainBootStrict) VIR_ENUM_DECL(virDomainFeature) VIR_ENUM_DECL(virDomainFeatureState) VIR_ENUM_DECL(virDomainLifecycle) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 28e24f9..f0f165f 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -135,6 +135,11 @@ VIR_ENUM_IMPL(virDomainBootMenu, VIR_DOMAIN_BOOT_MENU_LAST, "yes", "no") +VIR_ENUM_IMPL(virDomainBootStrict, VIR_DOMAIN_BOOT_STRICT_LAST, + "default", + "yes", + "no") + VIR_ENUM_IMPL(virDomainFeature, VIR_DOMAIN_FEATURE_LAST, "acpi", "apic", diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index d1a58f9..4949f08 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -112,6 +112,8 @@ virDomainBlockedReasonTypeFromString; virDomainBlockedReasonTypeToString; virDomainBootMenuTypeFromString; virDomainBootMenuTypeToString; +virDomainBootStrictTypeFromString; +virDomainBootStrictTypeToString; virDomainChrConsoleTargetTypeFromString; virDomainChrConsoleTargetTypeToString; virDomainChrDefForeach; -- 1.8.3.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- src/conf/domain_conf.c | 21 +++++++++++++++++++++ docs/formatdomain.html.in | 9 +++++++++ docs/schemas/domaincommon.rng | 10 ++++++++++ 3 files changed, 40 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index f0f165f..cb4c845 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -10721,6 +10721,20 @@ virDomainDefParseBootXML(xmlXPathContextPtr ctxt, VIR_FREE(tmp); } + tmp = virXPathString("string(./os/boot-strict[1]/@enable)", ctxt); + if (tmp) { + def->os.bootStrict = virDomainBootStrictTypeFromString(tmp); + if (def->os.bootStrict <= 0) { + /* In order not to break misconfigured machines, this should not + * emit an error, but rather set bootStrict to enabled (the default + * libvirt behavior). */ + VIR_WARN("requesting strict boot due to unknown option '%s'", + tmp); + def->os.bootStrict = VIR_DOMAIN_BOOT_STRICT_ENABLED; + } + VIR_FREE(tmp); + } + tmp = virXPathString("string(./os/bios[1]/@useserial)", ctxt); if (tmp) { if (STREQ(tmp, "yes")) { @@ -17103,6 +17117,13 @@ virDomainDefFormatInternal(virDomainDefPtr def, virBufferAsprintf(buf, " <bootmenu enable='%s'/>\n", enabled); } + if (def->os.bootStrict != VIR_DOMAIN_BOOT_STRICT_DEFAULT) { + const char *enabled = (def->os.bootStrict == + VIR_DOMAIN_BOOT_STRICT_ENABLED ? "yes" + : "no"); + virBufferAsprintf(buf, " <boot-strict enable='%s'/>\n", enabled); + } + if (def->os.bios.useserial || def->os.bios.rt_set) { virBufferAddLit(buf, " <bios"); if (def->os.bios.useserial) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index ff50214..bf21c46 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -106,6 +106,7 @@ <boot dev='hd'/> <boot dev='cdrom'/> <bootmenu enable='yes'/> + <boot-strict enable='yes'/> <smbios mode='sysinfo'/> <bios useserial='yes' rebootTimeout='0'/> </os> @@ -158,6 +159,14 @@ If not specified, the hypervisor default is used. <span class="since"> Since 0.8.3</span> </dd> + <dt><code>boot-strict</code></dt> + <dd>Whether or not to enable strict boot on guest startup. Strict boot + prevents booting from devices that have no boot order specification, + dependent on hypervisor support. The <code>enable</code> attribute can be + either "yes" or "no". If not specified, strict boot is enabled. OVMF + users should explicitly set <code>enable</code> to "no". + <span class="since">Since 1.2.2</span> + </dd> <dt><code>smbios</code></dt> <dd>How to populate SMBIOS information visible in the guest. The <code>mode</code> attribute must be specified, and is either diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 7f55f24..482f719 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -261,6 +261,16 @@ </element> </optional> <optional> + <element name="boot-strict"> + <attribute name="enable"> + <choice> + <value>yes</value> + <value>no</value> + </choice> + </attribute> + </element> + </optional> + <optional> <ref name="smbios"/> </optional> <optional> -- 1.8.3.1
On Wed, Jan 22, 2014 at 01:33:20AM +0100, Laszlo Ersek wrote:
Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- src/conf/domain_conf.c | 21 +++++++++++++++++++++ docs/formatdomain.html.in | 9 +++++++++ docs/schemas/domaincommon.rng | 10 ++++++++++ 3 files changed, 40 insertions(+)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index ff50214..bf21c46 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -106,6 +106,7 @@ <boot dev='hd'/> <boot dev='cdrom'/> <bootmenu enable='yes'/> + <boot-strict enable='yes'/> <smbios mode='sysinfo'/> <bios useserial='yes' rebootTimeout='0'/> </os>
Reviving the thread. Based on the discussions, I think I now agree that your suggestion to allow toggle of strict mode is probably our least worst way forward. I'd suggest that instead of introducing a new element here, we add an attribute to the <bios> element. eg perhaps this: <bios bootPolicy="strict|fallback"> BTW, as a general goal we want all the parsing/xml related changes in one patch. So your patches 1 + 2 could be squashed together. Regards, 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 :|
On 02/07/14 15:00, Daniel P. Berrange wrote:
On Wed, Jan 22, 2014 at 01:33:20AM +0100, Laszlo Ersek wrote:
Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- src/conf/domain_conf.c | 21 +++++++++++++++++++++ docs/formatdomain.html.in | 9 +++++++++ docs/schemas/domaincommon.rng | 10 ++++++++++ 3 files changed, 40 insertions(+)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index ff50214..bf21c46 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -106,6 +106,7 @@ <boot dev='hd'/> <boot dev='cdrom'/> <bootmenu enable='yes'/> + <boot-strict enable='yes'/> <smbios mode='sysinfo'/> <bios useserial='yes' rebootTimeout='0'/> </os>
Reviving the thread. Based on the discussions, I think I now agree that your suggestion to allow toggle of strict mode is probably our least worst way forward.
I'd suggest that instead of introducing a new element here, we add an attribute to the <bios> element. eg perhaps this:
<bios bootPolicy="strict|fallback">
BTW, as a general goal we want all the parsing/xml related changes in one patch. So your patches 1 + 2 could be squashed together.
Oh, I've implemented HALT parsing in OVMF since. See https://github.com/tianocore/edk2/commit/c3cf8daa I considered the issue solved, with the above OVMF commit. Do you still want me to rework this libvirt series? I can if you want me to. Thanks, Laszlo
On Fri, Feb 07, 2014 at 03:07:38PM +0100, Laszlo Ersek wrote:
On 02/07/14 15:00, Daniel P. Berrange wrote:
On Wed, Jan 22, 2014 at 01:33:20AM +0100, Laszlo Ersek wrote:
Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- src/conf/domain_conf.c | 21 +++++++++++++++++++++ docs/formatdomain.html.in | 9 +++++++++ docs/schemas/domaincommon.rng | 10 ++++++++++ 3 files changed, 40 insertions(+)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index ff50214..bf21c46 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -106,6 +106,7 @@ <boot dev='hd'/> <boot dev='cdrom'/> <bootmenu enable='yes'/> + <boot-strict enable='yes'/> <smbios mode='sysinfo'/> <bios useserial='yes' rebootTimeout='0'/> </os>
Reviving the thread. Based on the discussions, I think I now agree that your suggestion to allow toggle of strict mode is probably our least worst way forward.
I'd suggest that instead of introducing a new element here, we add an attribute to the <bios> element. eg perhaps this:
<bios bootPolicy="strict|fallback">
BTW, as a general goal we want all the parsing/xml related changes in one patch. So your patches 1 + 2 could be squashed together.
Oh, I've implemented HALT parsing in OVMF since. See
https://github.com/tianocore/edk2/commit/c3cf8daa
I considered the issue solved, with the above OVMF commit. Do you still want me to rework this libvirt series? I can if you want me to.
Based on your explanations it sounds like being able to turn off strict mode could still potentially be useful to people. So feel free to rework this series if you think its useful - I won't reject 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 :|
On 02/07/14 15:10, Daniel P. Berrange wrote:
On Fri, Feb 07, 2014 at 03:07:38PM +0100, Laszlo Ersek wrote:
On 02/07/14 15:00, Daniel P. Berrange wrote:
On Wed, Jan 22, 2014 at 01:33:20AM +0100, Laszlo Ersek wrote:
Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- src/conf/domain_conf.c | 21 +++++++++++++++++++++ docs/formatdomain.html.in | 9 +++++++++ docs/schemas/domaincommon.rng | 10 ++++++++++ 3 files changed, 40 insertions(+)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index ff50214..bf21c46 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -106,6 +106,7 @@ <boot dev='hd'/> <boot dev='cdrom'/> <bootmenu enable='yes'/> + <boot-strict enable='yes'/> <smbios mode='sysinfo'/> <bios useserial='yes' rebootTimeout='0'/> </os>
Reviving the thread. Based on the discussions, I think I now agree that your suggestion to allow toggle of strict mode is probably our least worst way forward.
I'd suggest that instead of introducing a new element here, we add an attribute to the <bios> element. eg perhaps this:
<bios bootPolicy="strict|fallback">
BTW, as a general goal we want all the parsing/xml related changes in one patch. So your patches 1 + 2 could be squashed together.
Oh, I've implemented HALT parsing in OVMF since. See
https://github.com/tianocore/edk2/commit/c3cf8daa
I considered the issue solved, with the above OVMF commit. Do you still want me to rework this libvirt series? I can if you want me to.
Based on your explanations it sounds like being able to turn off strict mode could still potentially be useful to people. So feel free to rework this series if you think its useful - I won't reject
Thank you. I'm re-appending it to my queue. Laszlo
Recent commit 96fddee3 ('qemu: add "-boot strict" to commandline whenever possible') breaks qemu boot order processing in OVMF. The qemu option '-boot strict=on' closes down the fw_cfg boot option list with a HALT string: /pci@i0cf8/ethernet@3/ethernet-phy@0 /pci@i0cf8/scsi@4/disk@0,0 HALT The fw_cfg boot order specification that is traditional between QEMU and SeaBIOS is not descriptive / expressive enough for perfect matching against UEFI device paths. First, a UEFI boot option (device path) includes the file path leading to the specific boot loader application; OFW device paths include no file paths. Second, UEFI device paths can include nodes that may have no OFW representation (eg. Vendor (GUID) hardware device path nodes, or nodes describing memory mapped code). When a preexistent UEFI boot option is *not* identified (matched) by any fw_cfg OpenFirmware boot entry after translating the latter, then '-boot strict=on' is ambiguous: - If the user has left out the boot option because he/she wants to omit it indeed, then *ignoring* the trailing HALT line (ie. '-boot strict=on') would be wrong. - If the user has left out the boot option because it cannot be expressed as an OpenFirmware boot entry (for example, the memory mapped UEFI shell), then *obeying* the trailing HALT line (ie. '-boot strict=on') would be wrong. ("Halting" would be inappropriate anyway in UEFI firmware; the user could be returned to the OVMF configration TUI at best.) Currently OVMF rejects the entire boot order specification when it encounters HALT (which is the clear and sensible choice in face of the above ambiguity). Unfortunately, commit 96fddee3 breaks this (and would also break the other two) approach(es), by hard-wiring the HALT entry. Therefore OVMF users need a way to disable '-boot strict=on'. For more details on OVMF behavior, please see the related RHBZ, <https://bugzilla.redhat.com/show_bug.cgi?id=1056258>. Regarding the implementation, it certainly complicates things that the libvirt default introduced by commit 96fddee3 -- "request strict boot", which we'd like to stick with -- is the opposite of qemu's default ("no strict boot"). As a result, it's not possible to decide in qemuParseCommandLine() uniquely whether '-boot strict=on' should be mapped to "default" or "enabled". The explicit "enabled" value seems safer. Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- src/qemu/qemu_command.c | 17 +++++- tests/qemuxml2argvtest.c | 4 ++ tests/qemuxml2argvdata/qemuxml2argv-boot-cdrom.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-boot-floppy.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-boot-network.xml | 1 + .../qemuxml2argv-boot-strict-off.args | 36 ++++++++++++ .../qemuxml2argv-boot-strict-off.xml | 67 ++++++++++++++++++++++ .../qemuxml2argv-clock-localtime.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-clock-utc.xml | 1 + .../qemuxml2argv-console-compat.xml | 1 + .../qemuxml2argv-disk-cdrom-empty.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom.xml | 1 + .../qemuxml2argv-disk-drive-boot-cdrom.xml | 1 + .../qemuxml2argv-disk-drive-boot-disk.xml | 1 + .../qemuxml2argv-disk-drive-cache-directsync.xml | 1 + .../qemuxml2argv-disk-drive-cache-unsafe.xml | 1 + .../qemuxml2argv-disk-drive-cache-v1-none.xml | 1 + .../qemuxml2argv-disk-drive-cache-v1-wb.xml | 1 + .../qemuxml2argv-disk-drive-cache-v2-none.xml | 1 + .../qemuxml2argv-disk-drive-cache-v2-wb.xml | 1 + .../qemuxml2argv-disk-drive-cache-v2-wt.xml | 1 + ...muxml2argv-disk-drive-error-policy-enospace.xml | 1 + .../qemuxml2argv-disk-drive-error-policy-stop.xml | 1 + ...rgv-disk-drive-error-policy-wreport-rignore.xml | 1 + .../qemuxml2argv-disk-drive-fmt-qcow.xml | 1 + .../qemuxml2argv-disk-drive-network-gluster.xml | 1 + .../qemuxml2argv-disk-drive-network-iscsi.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd-export.xml | 1 + ...xml2argv-disk-drive-network-nbd-ipv6-export.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd-ipv6.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd-unix.xml | 1 + .../qemuxml2argv-disk-drive-network-nbd.xml | 1 + ...emuxml2argv-disk-drive-network-rbd-ceph-env.xml | 1 + .../qemuxml2argv-disk-drive-network-rbd-ipv6.xml | 1 + .../qemuxml2argv-disk-drive-network-rbd.xml | 1 + .../qemuxml2argv-disk-drive-network-sheepdog.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-disk-floppy.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-disk-many.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-disk-usb.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-disk-virtio.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-disk-xenvbd.xml | 1 + .../qemuxml2argv-graphics-sdl-fullscreen.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-graphics-sdl.xml | 1 + .../qemuxml2argv-graphics-vnc-policy.xml | 1 + .../qemuxml2argv-graphics-vnc-sasl.xml | 1 + .../qemuxml2argv-graphics-vnc-socket.xml | 1 + .../qemuxml2argv-graphics-vnc-tls.xml | 1 + .../qemuxml2argv-graphics-vnc-websocket.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-graphics-vnc.xml | 1 + .../qemuxml2argv-hostdev-pci-address.xml | 1 + .../qemuxml2argv-hostdev-usb-address.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-hyperv.xml | 1 + .../qemuxml2argv-input-usbmouse.xml | 1 + .../qemuxml2argv-input-usbtablet.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-kvmclock.xml | 1 + .../qemuxml2argv-machine-core-off.xml | 1 + .../qemuxml2argv-machine-core-on.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-migrate.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-misc-acpi.xml | 1 + .../qemuxml2argv-misc-disable-s3.xml | 1 + .../qemuxml2argv-misc-disable-suspends.xml | 1 + .../qemuxml2argv-misc-enable-s4.xml | 1 + .../qemuxml2argv-misc-no-reboot.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml | 1 + .../qemuxml2argv-net-eth-ifname.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-net-eth.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-net-user.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-net-virtio.xml | 1 + .../qemuxml2argv-nographics-vga.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-nosharepages.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-parallel-tcp.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-pseries-disk.xml | 1 + .../qemuxml2argv-pseries-nvram.xml | 1 + .../qemuxml2argv-qemu-ns-no-env.xml | 1 + .../qemuxml2argv-reboot-timeout-disabled.xml | 1 + .../qemuxml2argv-reboot-timeout-enabled.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-restore-v1.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-restore-v2.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-dev.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-serial-file.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-serial-many.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-pty.xml | 1 + .../qemuxml2argv-serial-tcp-telnet.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-tcp.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml | 1 + .../qemuxml2argvdata/qemuxml2argv-serial-unix.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-serial-vc.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-smp.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-sound.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-watchdog.xml | 1 + 90 files changed, 209 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.xml diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 96b8825..c1b5269 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -8242,7 +8242,18 @@ qemuBuildCommandLine(virConnectPtr conn, if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_BOOT_STRICT)) { if (boot_nparams++) virBufferAddChar(&boot_buf, ','); - virBufferAddLit(&boot_buf, "strict=on"); + + if (def->os.bootStrict == VIR_DOMAIN_BOOT_STRICT_DISABLED) + virBufferAddLit(&boot_buf, "strict=off"); + else + virBufferAddLit(&boot_buf, "strict=on"); + } else if (def->os.bootStrict == VIR_DOMAIN_BOOT_STRICT_ENABLED) { + /* When QEMU doesn't support -boot strict, then the libvirt default + * ("enable strict boot") won't work. But we didn't complain in + * that situation before, so let's start complaining only when the + * user explicitly requests strict boot and we can't provide it. */ + VIR_WARN("strict boot is requested but not " + "supported by this QEMU binary"); } if (boot_nparams > 0) { @@ -11228,6 +11239,8 @@ qemuParseCommandLine(virCapsPtr qemuCaps, (def->os.arch == VIR_ARCH_X86_64)) def->features[VIR_DOMAIN_FEATURE_ACPI] = VIR_DOMAIN_FEATURE_STATE_ON; + def->os.bootStrict = VIR_DOMAIN_BOOT_STRICT_DISABLED; + #define WANT_VALUE() \ const char *val = progargv[++i]; \ if (!val) { \ @@ -11573,6 +11586,8 @@ qemuParseCommandLine(virCapsPtr qemuCaps, qemuParseCommandLineBootDevs(def, token); } else if (STRPREFIX(token, "menu=on")) { def->os.bootmenu = 1; + } else if (STRPREFIX(token, "strict=on")) { + def->os.bootStrict = VIR_DOMAIN_BOOT_STRICT_ENABLED; } else if (STRPREFIX(token, "reboot-timeout=")) { int num; char *endptr; diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index a25264e..6a8e054 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -609,6 +609,10 @@ mymain(void) QEMU_CAPS_DEVICE, QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_BOOT, QEMU_CAPS_BOOTINDEX, QEMU_CAPS_BOOT_STRICT, QEMU_CAPS_VIRTIO_BLK_SCSI, QEMU_CAPS_VIRTIO_BLK_SG_IO); + DO_TEST("boot-strict-off", + QEMU_CAPS_DEVICE, QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_BOOT, + QEMU_CAPS_BOOTINDEX, QEMU_CAPS_BOOT_STRICT, + QEMU_CAPS_VIRTIO_BLK_SCSI, QEMU_CAPS_VIRTIO_BLK_SG_IO); DO_TEST("bootloader", QEMU_CAPS_DOMID, QEMU_CAPS_KVM); DO_TEST("reboot-timeout-disabled", QEMU_CAPS_REBOOT_TIMEOUT); diff --git a/tests/qemuxml2argvdata/qemuxml2argv-boot-cdrom.xml b/tests/qemuxml2argvdata/qemuxml2argv-boot-cdrom.xml index b5c37bb..d7798c6 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-boot-cdrom.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-boot-cdrom.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='cdrom'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-boot-floppy.xml b/tests/qemuxml2argvdata/qemuxml2argv-boot-floppy.xml index e42f7ed..3daedc5 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-boot-floppy.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-boot-floppy.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='fd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-boot-network.xml b/tests/qemuxml2argvdata/qemuxml2argv-boot-network.xml index 8124f34..0a176de 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-boot-network.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-boot-network.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='network'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.args b/tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.args new file mode 100644 index 0000000..d51b3c7 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.args @@ -0,0 +1,36 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu \ +-S \ +-M pc \ +-m 214 \ +-smp 1 \ +-nographic \ +-nodefaults \ +-monitor unix:/tmp/test-monitor,server,nowait \ +-no-acpi \ +-boot strict=off \ +-usb \ +-drive file=/tmp/vda.img,if=none,id=drive-virtio-disk0 \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,\ +id=virtio-disk0,bootindex=3 \ +-drive file=/tmp/vdb.img,if=none,id=drive-virtio-disk1 \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,\ +id=virtio-disk1 \ +-drive file=/dev/HostVG/hda,if=none,id=drive-ide0-0-0 \ +-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ +-drive file=/dev/HostVG/hdb,if=none,id=drive-ide0-0-1 \ +-device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ +-drive file=/dev/HostVG/hdc,if=none,media=cdrom,id=drive-ide0-1-0 \ +-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,\ +bootindex=1 \ +-drive file=/dev/fd0,if=none,id=drive-fdc0-0-0 \ +-global isa-fdc.driveA=drive-fdc0-0-0 \ +-global isa-fdc.bootindexA=4 \ +-drive file=/dev/fd1,if=none,id=drive-fdc0-0-1 \ +-global isa-fdc.driveB=drive-fdc0-0-1 \ +-device virtio-net-pci,vlan=0,id=net0,mac=00:11:22:33:44:11,bus=pci.0,\ +addr=0x3,bootindex=2 \ +-net user,vlan=0,name=hostnet0 \ +-device virtio-net-pci,vlan=1,id=net1,mac=00:11:22:33:44:22,bus=pci.0,\ +addr=0x4 \ +-net user,vlan=1,name=hostnet1 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.xml b/tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.xml new file mode 100644 index 0000000..d4d595e --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-boot-strict-off.xml @@ -0,0 +1,67 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='cdrom'/> + <boot dev='network'/> + <boot dev='hd'/> + <boot dev='fd'/> + <boot-strict enable='no'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='file' device='disk'> + <source file='/tmp/vdb.img'/> + <target dev='vdb' bus='virtio'/> + </disk> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/hdb'/> + <target dev='hdb' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/hda'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <source file='/tmp/vda.img'/> + <target dev='vda' bus='virtio'/> + </disk> + <disk type='block' device='cdrom'> + <source dev='/dev/HostVG/hdc'/> + <target dev='hdc' bus='ide'/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <disk type='block' device='floppy'> + <source dev='/dev/fd1'/> + <target dev='fdb' bus='fdc'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='block' device='floppy'> + <source dev='/dev/fd0'/> + <target dev='fda' bus='fdc'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='fdc' index='0'/> + <controller type='ide' index='0'/> + <interface type='user'> + <mac address='00:11:22:33:44:11'/> + <model type='virtio'/> + </interface> + <interface type='user'> + <mac address='00:11:22:33:44:22'/> + <model type='virtio'/> + </interface> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-clock-localtime.xml b/tests/qemuxml2argvdata/qemuxml2argv-clock-localtime.xml index 2acb71f..c4e3422 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-clock-localtime.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-clock-localtime.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='localtime'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-clock-utc.xml b/tests/qemuxml2argvdata/qemuxml2argv-clock-utc.xml index 138a83a..1c04788 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-clock-utc.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-clock-utc.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-console-compat.xml b/tests/qemuxml2argvdata/qemuxml2argv-console-compat.xml index b1ee29c..742a039 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-console-compat.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-console-compat.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom-empty.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom-empty.xml index d8ff676..3f2a655 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom-empty.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom-empty.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom.xml index 75b9cec..6105092 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-cdrom.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml index 59ef29d..54e037b 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-cdrom.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='cdrom'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml index 0c9bc08..725c726 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-boot-disk.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-directsync.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-directsync.xml index 0b85fb1..b1b4dc5 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-directsync.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-directsync.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-unsafe.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-unsafe.xml index 4bd8e24..48de211 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-unsafe.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-unsafe.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-none.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-none.xml index 7fe9082..9550672 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-none.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-none.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wb.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wb.xml index f0e7df4..2ae56db 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wb.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wb.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-none.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-none.xml index 0beda48..e85699c 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-none.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-none.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wb.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wb.xml index 00730f7..6a10267 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wb.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wb.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wt.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wt.xml index 6ee75aa..6599262 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wt.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wt.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-enospace.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-enospace.xml index 92fcd8a..044762f 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-enospace.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-enospace.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-stop.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-stop.xml index 83d5dd0..c2b19c1 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-stop.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-stop.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-wreport-rignore.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-wreport-rignore.xml index ded9cd1..b2c5825 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-wreport-rignore.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-error-policy-wreport-rignore.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fmt-qcow.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fmt-qcow.xml index 85fe2a9..468dd11 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fmt-qcow.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fmt-qcow.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-gluster.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-gluster.xml index 7c1fdb1..bb76ca1 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-gluster.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-gluster.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.xml index a6b13ab..39f8efb 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-export.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-export.xml index dd52c39..98c2ce8 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-export.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-export.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6-export.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6-export.xml index c3bfa34..891da94 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6-export.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6-export.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6.xml index 8087f90..04240dc 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-ipv6.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-unix.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-unix.xml index 0955fee..89522c0 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-unix.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd-unix.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd.xml index e74b95f..0901a71 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-nbd.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-ceph-env.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-ceph-env.xml index bba512e..fb4b271 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-ceph-env.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-ceph-env.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-ipv6.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-ipv6.xml index 06e852d..eb73aa2 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-ipv6.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-ipv6.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd.xml index bba512e..fb4b271 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-sheepdog.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-sheepdog.xml index d20ca3e..3479833 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-sheepdog.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-sheepdog.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-floppy.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-floppy.xml index 8bbd324..e4cd9b9 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-floppy.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-floppy.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-many.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-many.xml index edcd015..2b61289 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-many.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-many.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-usb.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-usb.xml index 730c4f3..7632003 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-usb.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-usb.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio.xml index 3e2e550..5902eb1 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-virtio.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-xenvbd.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-xenvbd.xml index 3baf97d..b822704 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-xenvbd.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-xenvbd.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-graphics-sdl-fullscreen.xml b/tests/qemuxml2argvdata/qemuxml2argv-graphics-sdl-fullscreen.xml index 7793161..12bbfd8 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-graphics-sdl-fullscreen.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-graphics-sdl-fullscreen.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-graphics-sdl.xml b/tests/qemuxml2argvdata/qemuxml2argv-graphics-sdl.xml index 26fe28b..eaf4ecb 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-graphics-sdl.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-graphics-sdl.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-policy.xml b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-policy.xml index 6c95c8a..dd5dbe5 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-policy.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-policy.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-sasl.xml b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-sasl.xml index 75563df..0bf5020 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-sasl.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-sasl.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-socket.xml b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-socket.xml index 24c7eed..c855602 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-socket.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-socket.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-tls.xml b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-tls.xml index 75563df..0bf5020 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-tls.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-tls.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-websocket.xml b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-websocket.xml index dd0bb57..84402d8 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-websocket.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc-websocket.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.xml b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.xml index 6dcd076..144ec8a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-graphics-vnc.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-pci-address.xml b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-pci-address.xml index 422127c..13fcbd9 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-pci-address.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-pci-address.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-usb-address.xml b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-usb-address.xml index ee00634..9ff4f9b 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-usb-address.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-usb-address.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-hyperv.xml b/tests/qemuxml2argvdata/qemuxml2argv-hyperv.xml index bb36fc0..f74e2e7 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-hyperv.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-hyperv.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='network'/> + <boot-strict enable='no'/> </os> <features> <acpi/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-input-usbmouse.xml b/tests/qemuxml2argvdata/qemuxml2argv-input-usbmouse.xml index 0863737..931b11e 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-input-usbmouse.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-input-usbmouse.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-input-usbtablet.xml b/tests/qemuxml2argvdata/qemuxml2argv-input-usbtablet.xml index 03558dd..0a815ea 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-input-usbtablet.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-input-usbtablet.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-kvmclock.xml b/tests/qemuxml2argvdata/qemuxml2argv-kvmclock.xml index a187aaa..a0c3ecf 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-kvmclock.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-kvmclock.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='network'/> + <boot-strict enable='no'/> </os> <features> <pae/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.xml b/tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.xml index 5eb229f..7f1625b 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.xml b/tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.xml index 0dd5b39..1a14a62 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-migrate.xml b/tests/qemuxml2argvdata/qemuxml2argv-migrate.xml index 3a375fe..6404810 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-migrate.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-migrate.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-misc-acpi.xml b/tests/qemuxml2argvdata/qemuxml2argv-misc-acpi.xml index 6fe8a85..347daa8 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-misc-acpi.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-misc-acpi.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <features> <acpi/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-misc-disable-s3.xml b/tests/qemuxml2argvdata/qemuxml2argv-misc-disable-s3.xml index b9313e0..e9e3f67 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-misc-disable-s3.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-misc-disable-s3.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-misc-disable-suspends.xml b/tests/qemuxml2argvdata/qemuxml2argv-misc-disable-suspends.xml index f432732..fdef5c0 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-misc-disable-suspends.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-misc-disable-suspends.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-misc-enable-s4.xml b/tests/qemuxml2argvdata/qemuxml2argv-misc-enable-s4.xml index cea52f8..76646f6 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-misc-enable-s4.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-misc-enable-s4.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-misc-no-reboot.xml b/tests/qemuxml2argvdata/qemuxml2argv-misc-no-reboot.xml index 10c2d41..3681f4a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-misc-no-reboot.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-misc-no-reboot.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml b/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml index 6fe8a85..347daa8 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <features> <acpi/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-net-eth-ifname.xml b/tests/qemuxml2argvdata/qemuxml2argv-net-eth-ifname.xml index 8ad6eb7..3b1d975 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-net-eth-ifname.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-net-eth-ifname.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-net-eth.xml b/tests/qemuxml2argvdata/qemuxml2argv-net-eth.xml index 6f00fe1..f1f7c9d 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-net-eth.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-net-eth.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-net-user.xml b/tests/qemuxml2argvdata/qemuxml2argv-net-user.xml index 960b7aa..d1c6920 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-net-user.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-net-user.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-net-virtio.xml b/tests/qemuxml2argvdata/qemuxml2argv-net-virtio.xml index 195a3d9..5672d81 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-net-virtio.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-net-virtio.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-nographics-vga.xml b/tests/qemuxml2argvdata/qemuxml2argv-nographics-vga.xml index 3a375fe..6404810 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-nographics-vga.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-nographics-vga.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-nosharepages.xml b/tests/qemuxml2argvdata/qemuxml2argv-nosharepages.xml index 5e54cd0..6e0383f 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-nosharepages.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-nosharepages.xml @@ -10,6 +10,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-parallel-tcp.xml b/tests/qemuxml2argvdata/qemuxml2argv-parallel-tcp.xml index 60ea846..04ba9ed 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-parallel-tcp.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-parallel-tcp.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-disk.xml b/tests/qemuxml2argvdata/qemuxml2argv-pseries-disk.xml index dbbd6aa..f6d8fae 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-disk.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-disk.xml @@ -7,6 +7,7 @@ <os> <type arch='ppc64' machine='pseries'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-nvram.xml b/tests/qemuxml2argvdata/qemuxml2argv-pseries-nvram.xml index d001ee7..4a78f70 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-nvram.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-nvram.xml @@ -7,6 +7,7 @@ <os> <type arch='ppc64' machine='pseries'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-qemu-ns-no-env.xml b/tests/qemuxml2argvdata/qemuxml2argv-qemu-ns-no-env.xml index 29f84db..42bc3cb 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-qemu-ns-no-env.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-qemu-ns-no-env.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-disabled.xml b/tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-disabled.xml index 883a804..54aa10f 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-disabled.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-disabled.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='network'/> + <boot-strict enable='no'/> <bios rebootTimeout='-1'/> </os> <clock offset='utc'/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-enabled.xml b/tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-enabled.xml index a298b9d..ecd223a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-enabled.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-reboot-timeout-enabled.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='network'/> + <boot-strict enable='no'/> <bios rebootTimeout='128'/> </os> <clock offset='utc'/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-restore-v1.xml b/tests/qemuxml2argvdata/qemuxml2argv-restore-v1.xml index 138a83a..1c04788 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-restore-v1.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-restore-v1.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-restore-v2.xml b/tests/qemuxml2argvdata/qemuxml2argv-restore-v2.xml index 3a375fe..6404810 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-restore-v2.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-restore-v2.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-dev.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-dev.xml index b1a7429..0fcfef3 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-dev.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-dev.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-file.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-file.xml index 4335f43..4fd4d63 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-file.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-file.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-many.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-many.xml index 4829285..5150cda 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-many.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-many.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-pty.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-pty.xml index d2af760..ced9458 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-pty.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-pty.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-telnet.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-telnet.xml index 06ce154..919cb7c 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-telnet.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-telnet.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-tcp.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-tcp.xml index 493f8a1..855347a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-tcp.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-tcp.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml index d525965..3be5227 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-udp.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-unix.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-unix.xml index 8aa052d..0b8f501 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-unix.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-unix.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-serial-vc.xml b/tests/qemuxml2argvdata/qemuxml2argv-serial-vc.xml index 12107d7..4e64e1c 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-serial-vc.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-serial-vc.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smp.xml b/tests/qemuxml2argvdata/qemuxml2argv-smp.xml index 55bf16d..2a6b3c3 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-smp.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-smp.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <cpu> <topology sockets='2' cores='1' threads='1'/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound.xml b/tests/qemuxml2argvdata/qemuxml2argv-sound.xml index 0bd1185..5130a34 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-watchdog.xml b/tests/qemuxml2argvdata/qemuxml2argv-watchdog.xml index 32d57e0..2297005 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-watchdog.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-watchdog.xml @@ -7,6 +7,7 @@ <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> + <boot-strict enable='no'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> -- 1.8.3.1
This is similar to how os.bootmenu is handled. Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- src/parallels/parallels_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/parallels/parallels_driver.c b/src/parallels/parallels_driver.c index 33260ef..4a386c2 100644 --- a/src/parallels/parallels_driver.c +++ b/src/parallels/parallels_driver.c @@ -2091,6 +2091,7 @@ parallelsApplyChanges(virConnectPtr conn, virDomainObjPtr dom, virDomainDefPtr n if (!STREQ_NULLABLE(old->os.type, new->os.type) || old->os.arch != new->os.arch || new->os.machine != NULL || new->os.bootmenu != 0 || + new->os.bootStrict != 0 || new->os.kernel != NULL || new->os.initrd != NULL || new->os.cmdline != NULL || new->os.root != NULL || new->os.loader != NULL || new->os.bootloader != NULL || -- 1.8.3.1
On Wed, Jan 22, 2014 at 01:33:18AM +0100, Laszlo Ersek wrote:
Recently,
commit 96fddee322c7d39a57cfdc5e7be71326d597d30a Author: Laine Stump <laine@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. Danbiel -- |: 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 :|
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@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.
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@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. Therefore now we have a "survival policy" in OVMF that tacks *some* of the unmatched boot options to the end of the list. I *can* most certainly implement HALT parsing in OVMF, and make the survival policy dependent on presence or absence of HALT. But that still doesn't change the fact that you need to enable the user to decide about passing HALT of not. Obviously I need to describe the translations and to give you UEFI boot option (device path) examples, otherwise you apparently simply don't believe me. The following stuff is implemented in "OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c" in the edk2 tree. The OpenFirmware device path is what comes from qemu over fw_cfg, and the UEFI device path prefix is what the translation must output, in order for the pefix matching to work. (1) IDE disk, or IDE CD-ROM: // // OpenFirmware device path (IDE disk, IDE CD-ROM): // // /pci@i0cf8/ide@1,1/drive@0/disk@0 // ^ ^ ^ ^ ^ // | | | | master or slave // | | | primary or secondary // | PCI slot & function holding IDE controller // PCI root at system bus port, PIO // // UEFI device path: // // PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0) // ^ // fixed LUN (2) floppy disk: // // OpenFirmware device path (floppy disk): // // /pci@i0cf8/isa@1/fdc@03f0/floppy@0 // ^ ^ ^ ^ // | | | A: or B: // | | ISA controller io-port (hex) // | PCI slot holding ISA controller // PCI root at system bus port, PIO // // UEFI device path: // // PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0) // ^ // ACPI UID // (3) virtio-block disk: // // OpenFirmware device path (virtio-blk disk): // // /pci@i0cf8/scsi@6[,3]/disk@0,0 // ^ ^ ^ ^ ^ // | | | fixed // | | PCI function corresponding to disk // | | (optional) // | PCI slot holding disk // PCI root at system bus port, PIO // // UEFI device path prefix: // // PciRoot(0x0)/Pci(0x6,0x0)/HD( -- if PCI function is 0 or absent // PciRoot(0x0)/Pci(0x6,0x3)/HD( -- if PCI function is present and // nonzero // (4) virtio-scsi unit (including disk and CD-ROM): // // OpenFirmware device path (virtio-scsi disk): // // /pci@i0cf8/scsi@7[,3]/channel@0/disk@2,3 // ^ ^ ^ ^ ^ // | | | | LUN // | | | target // | | channel (unused, fixed 0) // | PCI slot[, function] holding SCSI controller // PCI root at system bus port, PIO // // UEFI device path prefix: // // PciRoot(0x0)/Pci(0x7,0x0)/Scsi(0x2,0x3) -- if PCI function is 0 // or absent // PciRoot(0x0)/Pci(0x7,0x3)/Scsi(0x2,0x3) -- if PCI function is // present and nonzero // (5) Ethernet // // OpenFirmware device path (Ethernet NIC): // // /pci@i0cf8/ethernet@3[,2]/ethernet-phy@0 // ^ ^ ^ // | | fixed // | PCI slot[, function] holding Ethernet card // PCI root at system bus port, PIO // // UEFI device path prefix (dependent on presence of nonzero PCI // function): // // PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400E15EEF,0x1) // PciRoot(0x0)/Pci(0x3,0x2)/MAC(525400E15EEF,0x1) // ^ ^ // MAC address IfType // (1 == Ethernet) // // (Some UEFI NIC drivers don't set 0x1 for IfType.) // Anything in fw_cfg that doesn't match any of these OpenFirmware patterns is non-translatable right now (notice how all the patterns describe PCI devices). But the question is not what I can currently recognize and translate in OVMF, the question is what can come over the fw_cfg channel. Here's two examples for you, of two valid and existent such UEFI device paths (breaking out each device path node on a separate line for readabiliy): (a) MemoryMapped(0xB,0x9F8C2000,0x9FFA1FFF)/ FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1) This happens to be the memory-mapped UEFI shell image. Please tell me how you can specify a boot preference for it, all across libvirt and qemu. You can rely on the GUID in the FvFile() node being well-known. (b) VenHw(C1E791A2-64CF-4B68-BDF1-1C31DABBDC84,0000131C00000000)/ HD(1,GPT,2F972E52-F7E0-4504-9FE7-F60E66352266,0x800,0x32000)/ \Image This is the file called "Image", in the root directory of the filesystem on the GPT hard disk partition identified by the HD() node, which can be reached behind the Vendor Hardware device that corresponds to the GUID and the rest of the binary garbage visible in the VenHw node. In detail this happens to be a virtio-mmio block device whose register range is mapped at 0x1C130000. Please tell me how you can express this boot preference across libvirt and qemu, in the OpenFirmware-format fw_cfg boot order. The user request I had gotten earlier was to keep (a) on the list. As I said above, the original approach was exactly -boot strict=on, which meant that I invariably killed the UEFI shell (option (a)), because it's unexpressible through the fw_cfg interface we have. After the user request we introduced the survival policy, which currently preserves all unmatched UEFI boot options as fallbacks (in their original relative order) that start with - neither PciRoot() (because we're saying that PCI devices can already be expressed fairly well), - nor HD() (this is a relative UEFI device path that the system can complete with its missing prefix devpath segment for matching, and we're saying that you likely want to boot HD() paths from PCI devices, which you can already express fairly well). This "policy" is obviously subject to change, it's just a heuristics that looks halfway reasonable, and keeps stuff that we *know* qemu (and likely OpenFirmware at all) can't express. You *can* say that I should make this survival policy dependent on HALT, but that still requires HALT not to be a *constant*. If you make HALT a constant, and I comply with it in OVMF, then the user can never reach the UEFI shell as a fallback. If you make HALT a constant, and I ignore it in OVMF, then I might reach a (say) CD-ROM entry in OVMF, even if the user doesn't specify it. If you make HALT configurable, then I *could* comply with it, because the user can add or remove it as he/she wishes. I'm unable to describe the problem any better than this, sorry. Thanks Laszlo
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@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 :|
On 01/23/14 15:58, Daniel P. Berrange wrote:
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@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.
You are technically right. I only have a problem with the word "hacking". Setting UEFI boot options (which also includes saving them in flash memory, which indeed can be considered part of the firmware), is *valid*. It's not "going behind" anyone's back. It's a perfectly valid thing to do in a UEFI guest (even at runtime, with the efibootmgr Linux utility for example).
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.
I agree that wrapper scripts are unsupportable. I disagree that users setting their persistent boot variables form inside the guest fall in the same category. That feature is an unalienable part of UEFI.
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.
I understand.
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.
We'd face two hurdles towards this goal. - The first is that you'd need to get a basically free-form string through. Technically it wouldn't be very hard, but it's completely foreign from the current bootindex concept in libvirt/qemu. In UEFI, "bootable device" can refer to something that's just a chunk of guest RAM for qemu. - The second hurdle is that you couldn't *offer* the host-side user sane choices (device paths for UEFI boot options) beyond a limit. This is because device paths come to existence by the execution and stacking of UEFI drivers, and their binding to devices. Notice that the current OVMF approach is not generate device paths It is translate OFW paths to UEFI devpath prefixes, heuristically, and try to match them against existent device paths that have come to be due to the execution of the driver stack When a user is picking a new boot option at the UEFI config screen, or at the UEFI shell prompt, then those UEFI drivers *exist*. The device paths can be enumerated, traversed, and the user can indeed browse the file systems on various devices, and pick whatever he wants. Then the corresponding device path is saved, and UEFI can boot it (and OVMF can match against it too). When a user tries to pick a new boot option at runtime (ie. after ExitBootServices(), eg. with efibootmgr, the UEFI drivers and the device paths generated by them don't exist. Consequently efibootmgr can only create relative HD() boot paths (because it can access the GUIDs in GPT partition tables at runtime). "Relative HD() boot option" is a supported concept in UEFI, because the GUID in the GPT entry is globally unique in separation too, so the UEFI code can look it up at boot time, wherever it is. The filename to boot from that filesystem must me specified though. As soon as you want to configure a netboot (PXE) option, you need to supply extra information on efibootmgr's command line, because the "relative NIC boot option" concept doesn't exist in UEFI. So in libvirt the same issue would come up. By browsing the guest's disks, relative HD() boot paths could be generated and offered, but nothing else. No netboot option that's directly bootable by UEFI, and certainly no option for the memory mapped shell. We'd have to invent some simple grammar that would trickle from libvirt to qemu to OVMF. Like GPT GUIDs + filenams for disk boots, MACs + remote filenames for NICs (PXE), and the word SHELL for the shell. Then OVMF's own boot policy could try to look these up between the existing handles and device paths, and turn them into real boot options. Ad absurdum, a "UEFI guest agent" could be imagined (hw serial port is available, virtio-serial driver could be written), providing libvirt with "everything". I guess all this is possible to implement in a multi-(month|year) dedicated project. Alas, hardwiring '-boot strict=on' is breaking the OVMF logic *right now*. If you're opposed to take this series, then I'll change OVMF to recognize and ignore HALT. It won't be the Right Thing (TM) -- because a command line qemu user passing '-boot strict=on' manually, and *not* wanting to boot the shell, might be surprised -- but it will be the least wrong solution for now. Leaving the code as-is breaks the current boot order logic 100%. Obeying HALT (which cannot be turned off) would prevent all libvirt+OVMF users from reaching the UEFI shell (which people do want to reach). Do you suggest that I do that? I'm fine with it (I even started coding it before deciding to fix libvirt instead), so please feel free to suggest that. Thanks! Laszlo
On Thu, Jan 23, 2014 at 05:25:18PM +0100, Laszlo Ersek wrote:
On 01/23/14 15:58, Daniel P. Berrange wrote:
I disagree that users setting their persistent boot variables form inside the guest fall in the same category. That feature is an unalienable part of UEFI.
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.
I understand.
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.
We'd face two hurdles towards this goal.
- The first is that you'd need to get a basically free-form string through. Technically it wouldn't be very hard, but it's completely foreign from the current bootindex concept in libvirt/qemu.
In UEFI, "bootable device" can refer to something that's just a chunk of guest RAM for qemu.
- The second hurdle is that you couldn't *offer* the host-side user sane choices (device paths for UEFI boot options) beyond a limit. This is because device paths come to existence by the execution and stacking of UEFI drivers, and their binding to devices.
Ok, I think I understand the problem more now. Would there be any sense in defining an generic <boot dev="config"/> option to indicate that UEFI should try the config settings that the user has defined inside the UEFI config partition ? If we use the strict=on|off setting, the user's config settings are only usable as the very last fallback option, once all the explicitly listed options have been tried. If we had a <boot dev="config"> we would perhaps be able to express ordering such as <boot dev="hd"> <boot dev="config"> <boot dev="cdrom"> without having to invent a impossibly complicated grammer to express all possible UEFI bootable device options ? Regards, 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 :|
On 01/28/14 13:10, Daniel P. Berrange wrote:
On Thu, Jan 23, 2014 at 05:25:18PM +0100, Laszlo Ersek wrote:
On 01/23/14 15:58, Daniel P. Berrange wrote:
I disagree that users setting their persistent boot variables form inside the guest fall in the same category. That feature is an unalienable part of UEFI.
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.
I understand.
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.
We'd face two hurdles towards this goal.
- The first is that you'd need to get a basically free-form string through. Technically it wouldn't be very hard, but it's completely foreign from the current bootindex concept in libvirt/qemu.
In UEFI, "bootable device" can refer to something that's just a chunk of guest RAM for qemu.
- The second hurdle is that you couldn't *offer* the host-side user sane choices (device paths for UEFI boot options) beyond a limit. This is because device paths come to existence by the execution and stacking of UEFI drivers, and their binding to devices.
Ok, I think I understand the problem more now. Would there be any sense in defining an generic <boot dev="config"/> option to indicate that UEFI should try the config settings that the user has defined inside the UEFI config partition ?
This probably makes sense, yes. It is identical to the case when no boot order at all is passed down via fw_cfg. (It is also identical to the case when some boot order *is* passed down, but OVMF finds no match at all. In this case the UEFI boot order is not touched.)
If we use the strict=on|off setting, the user's config settings are only usable as the very last fallback option, once all the explicitly listed options have been tried.
Yes. The idea behind the current code was: - want to go fully with the existent UEFI boot order: pass no OFW boot order over fw_cfg, - want to reorder existing boot options (and drop the unselected ones, except those in the "survival policy"): pass some OFW boot order via fw_cfg and make sure there's at least one match.
If we had a <boot dev="config"> we would perhaps be able to express ordering such as
<boot dev="hd"> <boot dev="config"> <boot dev="cdrom">
without having to invent a impossibly complicated grammer to express all possible UEFI bootable device options ?
What does this specification mean? Like, - try to match "hd" against the UEFI boot options, and move it to the beginning if it exists, - same for "cdrom", but move it to the end, - keep the rest in the middle? Thanks, Laszlo
On Tue, Jan 28, 2014 at 01:33:22PM +0100, Laszlo Ersek wrote:
On 01/28/14 13:10, Daniel P. Berrange wrote:
On Thu, Jan 23, 2014 at 05:25:18PM +0100, Laszlo Ersek wrote:
On 01/23/14 15:58, Daniel P. Berrange wrote:
I disagree that users setting their persistent boot variables form inside the guest fall in the same category. That feature is an unalienable part of UEFI.
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.
I understand.
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.
We'd face two hurdles towards this goal.
- The first is that you'd need to get a basically free-form string through. Technically it wouldn't be very hard, but it's completely foreign from the current bootindex concept in libvirt/qemu.
In UEFI, "bootable device" can refer to something that's just a chunk of guest RAM for qemu.
- The second hurdle is that you couldn't *offer* the host-side user sane choices (device paths for UEFI boot options) beyond a limit. This is because device paths come to existence by the execution and stacking of UEFI drivers, and their binding to devices.
Ok, I think I understand the problem more now. Would there be any sense in defining an generic <boot dev="config"/> option to indicate that UEFI should try the config settings that the user has defined inside the UEFI config partition ?
This probably makes sense, yes. It is identical to the case when no boot order at all is passed down via fw_cfg.
(It is also identical to the case when some boot order *is* passed down, but OVMF finds no match at all. In this case the UEFI boot order is not touched.)
If we use the strict=on|off setting, the user's config settings are only usable as the very last fallback option, once all the explicitly listed options have been tried.
Yes.
The idea behind the current code was: - want to go fully with the existent UEFI boot order: pass no OFW boot order over fw_cfg, - want to reorder existing boot options (and drop the unselected ones, except those in the "survival policy"): pass some OFW boot order via fw_cfg and make sure there's at least one match.
If we had a <boot dev="config"> we would perhaps be able to express ordering such as
<boot dev="hd"> <boot dev="config"> <boot dev="cdrom">
without having to invent a impossibly complicated grammer to express all possible UEFI bootable device options ?
What does this specification mean? Like, - try to match "hd" against the UEFI boot options, and move it to the beginning if it exists, - same for "cdrom", but move it to the end, - keep the rest in the middle?
Roughly, but I'd expect 'hd' and 'cdrom' to be used against whatever HD and CDROM devices exist in hardware, regardless of what the UEFI setup currently is. 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 :|
On 01/28/14 13:36, Daniel P. Berrange wrote:
On Tue, Jan 28, 2014 at 01:33:22PM +0100, Laszlo Ersek wrote:
On 01/28/14 13:10, Daniel P. Berrange wrote:
On Thu, Jan 23, 2014 at 05:25:18PM +0100, Laszlo Ersek wrote:
On 01/23/14 15:58, Daniel P. Berrange wrote:
I disagree that users setting their persistent boot variables form inside the guest fall in the same category. That feature is an unalienable part of UEFI.
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.
I understand.
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.
We'd face two hurdles towards this goal.
- The first is that you'd need to get a basically free-form string through. Technically it wouldn't be very hard, but it's completely foreign from the current bootindex concept in libvirt/qemu.
In UEFI, "bootable device" can refer to something that's just a chunk of guest RAM for qemu.
- The second hurdle is that you couldn't *offer* the host-side user sane choices (device paths for UEFI boot options) beyond a limit. This is because device paths come to existence by the execution and stacking of UEFI drivers, and their binding to devices.
Ok, I think I understand the problem more now. Would there be any sense in defining an generic <boot dev="config"/> option to indicate that UEFI should try the config settings that the user has defined inside the UEFI config partition ?
This probably makes sense, yes. It is identical to the case when no boot order at all is passed down via fw_cfg.
(It is also identical to the case when some boot order *is* passed down, but OVMF finds no match at all. In this case the UEFI boot order is not touched.)
If we use the strict=on|off setting, the user's config settings are only usable as the very last fallback option, once all the explicitly listed options have been tried.
Yes.
The idea behind the current code was: - want to go fully with the existent UEFI boot order: pass no OFW boot order over fw_cfg, - want to reorder existing boot options (and drop the unselected ones, except those in the "survival policy"): pass some OFW boot order via fw_cfg and make sure there's at least one match.
If we had a <boot dev="config"> we would perhaps be able to express ordering such as
<boot dev="hd"> <boot dev="config"> <boot dev="cdrom">
without having to invent a impossibly complicated grammer to express all possible UEFI bootable device options ?
What does this specification mean? Like, - try to match "hd" against the UEFI boot options, and move it to the beginning if it exists, - same for "cdrom", but move it to the end, - keep the rest in the middle?
Roughly, but I'd expect 'hd' and 'cdrom' to be used against whatever HD and CDROM devices exist in hardware, regardless of what the UEFI setup currently is.
The problem with this is that the high-level concept of any hard disk is already translated to list of specific hard disks inside qemu. By the time OVMF looks at the fw_cfg blob carrying the boot entries, those are all individual devices in OFW notation. The logic that does this expansion is part of libvirt of course (because libvirt is the one passing the ,bootindex=N properties to qemu). We might want to move this logic lower down, but we'd need a format (a channel) from libvirt to qemu to OVMF, in order to communicate the intent to exercise such "device type filtering" in OVMF. Thanks Laszlo
On Tue, Jan 28, 2014 at 01:47:13PM +0100, Laszlo Ersek wrote:
On 01/28/14 13:36, Daniel P. Berrange wrote:
On Tue, Jan 28, 2014 at 01:33:22PM +0100, Laszlo Ersek wrote:
On 01/28/14 13:10, Daniel P. Berrange wrote:
On Thu, Jan 23, 2014 at 05:25:18PM +0100, Laszlo Ersek wrote:
On 01/23/14 15:58, Daniel P. Berrange wrote:
I disagree that users setting their persistent boot variables form inside the guest fall in the same category. That feature is an unalienable part of UEFI.
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.
I understand.
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.
We'd face two hurdles towards this goal.
- The first is that you'd need to get a basically free-form string through. Technically it wouldn't be very hard, but it's completely foreign from the current bootindex concept in libvirt/qemu.
In UEFI, "bootable device" can refer to something that's just a chunk of guest RAM for qemu.
- The second hurdle is that you couldn't *offer* the host-side user sane choices (device paths for UEFI boot options) beyond a limit. This is because device paths come to existence by the execution and stacking of UEFI drivers, and their binding to devices.
Ok, I think I understand the problem more now. Would there be any sense in defining an generic <boot dev="config"/> option to indicate that UEFI should try the config settings that the user has defined inside the UEFI config partition ?
This probably makes sense, yes. It is identical to the case when no boot order at all is passed down via fw_cfg.
(It is also identical to the case when some boot order *is* passed down, but OVMF finds no match at all. In this case the UEFI boot order is not touched.)
If we use the strict=on|off setting, the user's config settings are only usable as the very last fallback option, once all the explicitly listed options have been tried.
Yes.
The idea behind the current code was: - want to go fully with the existent UEFI boot order: pass no OFW boot order over fw_cfg, - want to reorder existing boot options (and drop the unselected ones, except those in the "survival policy"): pass some OFW boot order via fw_cfg and make sure there's at least one match.
If we had a <boot dev="config"> we would perhaps be able to express ordering such as
<boot dev="hd"> <boot dev="config"> <boot dev="cdrom">
without having to invent a impossibly complicated grammer to express all possible UEFI bootable device options ?
What does this specification mean? Like, - try to match "hd" against the UEFI boot options, and move it to the beginning if it exists, - same for "cdrom", but move it to the end, - keep the rest in the middle?
Roughly, but I'd expect 'hd' and 'cdrom' to be used against whatever HD and CDROM devices exist in hardware, regardless of what the UEFI setup currently is.
The problem with this is that the high-level concept of
any hard disk
is already translated to
list of specific hard disks
inside qemu. By the time OVMF looks at the fw_cfg blob carrying the boot entries, those are all individual devices in OFW notation. The logic that does this expansion is part of libvirt of course (because libvirt is the one passing the ,bootindex=N properties to qemu).
Oh right yes. If libvirt is specifying bootindex properties, then we wouldn't be specifying the boot device types. We use one or the other but not both. So in the case where we used bootindex=N syntax we'd need to figure out how to express the concept of user config in the XML / CLI still. 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 :|
Il 22/01/2014 13:40, Laszlo Ersek ha scritto:
(b)
VenHw(C1E791A2-64CF-4B68-BDF1-1C31DABBDC84,0000131C00000000)/ HD(1,GPT,2F972E52-F7E0-4504-9FE7-F60E66352266,0x800,0x32000)/ \Image
This is the file called "Image", in the root directory of the filesystem on the GPT hard disk partition identified by the HD() node, which can be reached behind the Vendor Hardware device that corresponds to the GUID and the rest of the binary garbage visible in the VenHw node.
In detail this happens to be a virtio-mmio block device whose register range is mapped at 0x1C130000.
This would probably be something like /virtio-mmio@1c130000/disk@0,0 As a stopgap solution, you could keep the UEFI shell in the boot order if it is present in the UEFI boot order, even if the fw_cfg boot order includes HALT. Would relative HD() paths still work? Paolo
On 01/28/14 12:54, Paolo Bonzini wrote:
Il 22/01/2014 13:40, Laszlo Ersek ha scritto:
(b)
VenHw(C1E791A2-64CF-4B68-BDF1-1C31DABBDC84,0000131C00000000)/ HD(1,GPT,2F972E52-F7E0-4504-9FE7-F60E66352266,0x800,0x32000)/ \Image
This is the file called "Image", in the root directory of the filesystem on the GPT hard disk partition identified by the HD() node, which can be reached behind the Vendor Hardware device that corresponds to the GUID and the rest of the binary garbage visible in the VenHw node.
In detail this happens to be a virtio-mmio block device whose register range is mapped at 0x1C130000.
This would probably be something like
/virtio-mmio@1c130000/disk@0,0
As a stopgap solution, you could keep the UEFI shell in the boot order if it is present in the UEFI boot order, even if the fw_cfg boot order includes HALT.
Indeed, this is precisely what I've called "recognizing and ignoring HALT", and "the least wrong solution", elsewhere in this discussion. I wanted people to state explicitly that this workaround in OVMF is preferred to the libvirt patches. Now I can go forward and code it.
Would relative HD() paths still work?
Yes, they would. HALT will simply be considered "end of list". Thank you! Laszlo
Il 28/01/2014 13:16, Laszlo Ersek ha scritto:
On 01/28/14 12:54, Paolo Bonzini wrote:
Il 22/01/2014 13:40, Laszlo Ersek ha scritto:
(b)
VenHw(C1E791A2-64CF-4B68-BDF1-1C31DABBDC84,0000131C00000000)/ HD(1,GPT,2F972E52-F7E0-4504-9FE7-F60E66352266,0x800,0x32000)/ \Image
This is the file called "Image", in the root directory of the filesystem on the GPT hard disk partition identified by the HD() node, which can be reached behind the Vendor Hardware device that corresponds to the GUID and the rest of the binary garbage visible in the VenHw node.
In detail this happens to be a virtio-mmio block device whose register range is mapped at 0x1C130000.
This would probably be something like
/virtio-mmio@1c130000/disk@0,0
As a stopgap solution, you could keep the UEFI shell in the boot order if it is present in the UEFI boot order, even if the fw_cfg boot order includes HALT.
Indeed, this is precisely what I've called "recognizing and ignoring HALT", and "the least wrong solution", elsewhere in this discussion.
I'm not sure if this would be *ignoring* HALT. For example the CD-ROMs would not be included in the list. Given your note that "you can rely on the GUUID in the FvFile() node being well-known", HALT could look for entries including FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1), copy them if present, and then conclude the boot order. Or in an alternative interpretation, HALT could copy all the MemoryMapped entries, and then conclude the boot order. You're more competent than me in choosing the best interpretation.
Would relative HD() paths still work?
Yes, they would. HALT will simply be considered "end of list".
... and earlier entries would be matched to the relative HD() path, because that relative path is "expanded" to the full path before your translation code runs. Right? Paolo
On 01/28/14 13:25, Paolo Bonzini wrote:
Il 28/01/2014 13:16, Laszlo Ersek ha scritto:
On 01/28/14 12:54, Paolo Bonzini wrote:
Il 22/01/2014 13:40, Laszlo Ersek ha scritto:
(b)
VenHw(C1E791A2-64CF-4B68-BDF1-1C31DABBDC84,0000131C00000000)/ HD(1,GPT,2F972E52-F7E0-4504-9FE7-F60E66352266,0x800,0x32000)/ \Image
This is the file called "Image", in the root directory of the filesystem on the GPT hard disk partition identified by the HD() node, which can be reached behind the Vendor Hardware device that corresponds to the GUID and the rest of the binary garbage visible in the VenHw node.
In detail this happens to be a virtio-mmio block device whose register range is mapped at 0x1C130000.
This would probably be something like
/virtio-mmio@1c130000/disk@0,0
As a stopgap solution, you could keep the UEFI shell in the boot order if it is present in the UEFI boot order, even if the fw_cfg boot order includes HALT.
Indeed, this is precisely what I've called "recognizing and ignoring HALT", and "the least wrong solution", elsewhere in this discussion.
I'm not sure if this would be *ignoring* HALT. For example the CD-ROMs would not be included in the list.
Right, in that sense it wouldn't mean "ignoring". HALT would be ignored in the sense that the UEFI shell would still be tacked on. IOW a user passing -boot strict=on on the qemu command line could not *prevent* keeping the UEFI shell at the end of the list.
Given your note that "you can rely on the GUUID in the FvFile() node being well-known", HALT could look for entries including FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1), copy them if present, and then conclude the boot order. Or in an alternative interpretation, HALT could copy all the MemoryMapped entries, and then conclude the boot order. You're more competent than me in choosing the best interpretation.
This is precisely what I meant. The "survival policy" does just this. (The set of entries to keep alive that it filters for is a bit different, but the idea is the same.)
Would relative HD() paths still work?
Yes, they would. HALT will simply be considered "end of list".
... and earlier entries would be matched to the relative HD() path, because that relative path is "expanded" to the full path before your translation code runs. Right?
Correct. (Technically, I call the expansion routine as part of the translation myself, but what matters is that matching is performed on the expanded UEFI device paths.) Thanks, Laszlo
On 01/22/14 11:45, Daniel P. Berrange wrote:
On Wed, Jan 22, 2014 at 01:33:18AM +0100, Laszlo Ersek wrote:
Recently,
commit 96fddee322c7d39a57cfdc5e7be71326d597d30a Author: Laine Stump <laine@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.
Have you read the description in patch 3 too? The basic idea of HALT is that you specify everything in the fw_cfg file that you want to boot from, and expect that the firmware attempt no other option to boot. This assumes that you are able to *express* all places that you want to boot from in the fw_cfg boot specification. Under UEFI there are places to boot from that you simply cannot express in fw_cfg. If you specify HALT, then you'll never reach those places, not even as fallbacks. And users do want to reach those places as fallbacks. Of course you can say "well then the user should not specify HALT". Which is exactly the point of this patchset. Laszlo
On Wed, Jan 22, 2014 at 12:47:41PM +0100, Laszlo Ersek wrote:
On 01/22/14 11:45, Daniel P. Berrange wrote:
On Wed, Jan 22, 2014 at 01:33:18AM +0100, Laszlo Ersek wrote:
Recently,
commit 96fddee322c7d39a57cfdc5e7be71326d597d30a Author: Laine Stump <laine@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.
Have you read the description in patch 3 too?
The basic idea of HALT is that you specify everything in the fw_cfg file that you want to boot from, and expect that the firmware attempt no other option to boot. This assumes that you are able to *express* all places that you want to boot from in the fw_cfg boot specification.
Under UEFI there are places to boot from that you simply cannot express in fw_cfg. If you specify HALT, then you'll never reach those places, not even as fallbacks. And users do want to reach those places as fallbacks.
That is a pretty nebulous statement which I find hard to believe. We have a list of device types to attempt boot from (floppy/disk/cdrom/network) or a list of device instance boot order priorities. I fail to see how OVMF can be incapable of figuring that out. Regards, 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 :|
participants (4)
-
Daniel P. Berrange -
Laine Stump -
Laszlo Ersek -
Paolo Bonzini