6:33 p.m.
Recently,
commit 96fddee322c7d39a57cfdc5e7be71326d597d30a
Author: Laine Stump <laine(a)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
6:33 p.m.
New subject: [libvirt] [PATCH 1/4] domain: introduce os.bootStrict
This field will allow the user to disable strict booting under qemu.
Signed-off-by: Laszlo Ersek <lersek(a)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
6:33 p.m.
New subject: [libvirt] [PATCH 2/4] domain: parse and format os.bootStrict from/to XML
Signed-off-by: Laszlo Ersek <lersek(a)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
8 a.m.
New subject: [libvirt] [PATCH 2/4] domain: parse and format os.bootStrict from/to XML
On Wed, Jan 22, 2014 at 01:33:20AM +0100, Laszlo Ersek wrote:
Signed-off-by: Laszlo Ersek <lersek(a)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 :|
8:07 a.m.
New subject: [libvirt] [PATCH 2/4] domain: parse and format os.bootStrict from/to XML
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(a)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
8:10 a.m.
New subject: [libvirt] [PATCH 2/4] domain: parse and format os.bootStrict from/to XML
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(a)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 :|
8:40 a.m.
New subject: [libvirt] [PATCH 2/4] domain: parse and format os.bootStrict from/to XML
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(a)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
6:33 p.m.
New subject: [libvirt] [PATCH 3/4] qemu: parse and format os.bootStrict from/to command line
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(a)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
6:33 p.m.
New subject: [libvirt] [PATCH 4/4] parallels: reject non-default os.bootStrict
This is similar to how os.bootmenu is handled.
Signed-off-by: Laszlo Ersek <lersek(a)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
4:45 a.m.
On Wed, Jan 22, 2014 at 01:33:18AM +0100, Laszlo Ersek wrote:
Recently,
commit 96fddee322c7d39a57cfdc5e7be71326d597d30a
Author: Laine Stump <laine(a)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 :|
5:45 a.m.
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(a)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.
6:40 a.m.
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(a)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
8:58 a.m.
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(a)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 :|
10:25 a.m.
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(a)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
6:10 a.m.
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 :|
6:33 a.m.
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
6:36 a.m.
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 :|
6:47 a.m.
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
6:49 a.m.
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 :|
5:54 a.m.
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
6:16 a.m.
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
6:25 a.m.
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
6:41 a.m.
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
5:47 a.m.
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(a)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
5:52 a.m.
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(a)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 :|
3944
days inactive
3960
days old
24 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Laine Stump -
Laszlo Ersek -
Paolo Bonzini