[libvirt] [PATCH 00/23] conf: domain: Buffer and XPath handling refactors
by Peter Krempa
Peter Krempa (23):
util: xml: Enforce return value check from virXMLFormatElement
conf: Use virXMLFormatElement in virDomainControllerDriverFormat
conf: Use virXMLFormatElement in virDomainControllerDefFormat
conf: Refactor virDomainMemballoonDefFormat
conf: Refactor virDomainWatchdogDefFormat
conf: Refactor virDomainPanicDefFormat
conf: Refactor formatting of 'driver' in virDomainRNGDefFormat
conf: Refactor virDomainInputDefFormat
conf: Refactor virDomainHubDefFormat
conf: Split out formatting of 'blkiotune' from
virDomainDefFormatInternal
conf: Split out domain features formatting from
virDomainDefFormatInternal
conf: Refactor control flow in virDomainDefFormatFeatures
conf: Rename temp buffers in virDomainDefFormatFeatures
conf: Remove impossible error in virDomainDefFormatFeatures
conf: Simplify lifecycle of temp buffers in virDomainDefFormatFeatures
conf: Avoid extra set of temp buffers in virDomainDefFormatFeatures
conf: Avoid extra scope when formatting 'smm' feature
conf: Avoid formatting empty <capabilities> element
conf: Refactor formating of 'capabilities' features
conf: Use virXMLFormatElement in virDomainDefFormatFeatures
conf: domain: Use VIR_AUTOCLEAN(virBuffer) where appropriate
conf: Move XPath context node in descendants of virSysinfoParseXML
conf: domain: Use VIR_XPATH_NODE_AUTORESTORE where appropriate
src/conf/domain_conf.c | 1184 +++++++----------
src/util/virxml.h | 3 +-
.../lxcconf2xmldata/lxcconf2xml-blkiotune.xml | 3 +-
.../lxcconf2xml-cpusettune.xml | 3 +-
tests/lxcconf2xmldata/lxcconf2xml-cputune.xml | 3 +-
tests/lxcconf2xmldata/lxcconf2xml-idmap.xml | 3 +-
.../lxcconf2xml-macvlannetwork.xml | 3 +-
tests/lxcconf2xmldata/lxcconf2xml-memtune.xml | 3 +-
.../lxcconf2xml-miscnetwork.xml | 3 +-
.../lxcconf2xml-nonenetwork.xml | 3 +-
.../lxcconf2xmldata/lxcconf2xml-nonetwork.xml | 3 +-
.../lxcconf2xml-physnetwork.xml | 3 +-
.../lxcconf2xml-vlannetwork.xml | 3 +-
13 files changed, 485 insertions(+), 735 deletions(-)
--
2.20.1
5 years, 8 months
[libvirt] [PATCH 0/6] Couple of storage driver improvements
by Michal Privoznik
*** BLURB HERE ***
Michal Prívozník (6):
storage_backend_iscsi_direct: Simplify vol zeroing
virISCSIDirectReportLuns: Drop ClearVols
storageVolWipePattern: Don't take shortcut to refreshPool()
storage_driver: Introduce storagePoolRefreshImpl()
storagePoolRefreshFailCleanup: Clear volumes on failed refresh
virsh-pool: Offer only active pool for pool-refresh completer
src/storage/storage_backend_gluster.c | 2 -
src/storage/storage_backend_iscsi_direct.c | 21 ++----
src/storage/storage_backend_logical.c | 12 +---
src/storage/storage_backend_rbd.c | 4 +-
src/storage/storage_driver.c | 77 ++++++++++++----------
src/storage/storage_util.c | 2 -
tools/virsh-pool.c | 2 +-
7 files changed, 55 insertions(+), 65 deletions(-)
--
2.19.2
5 years, 8 months
[libvirt] [PATCH] qemu: Don't set migration caps when changing postcopy bandwidth
by Jiri Denemark
The qemuMigrationParamsApply internal API was designed to apply all
migration parameters and capabilities before we start to migrate a
domain. The API can also be called outside migration job, e.g., via a
call to qemuDomainMigrateSetMaxSpeed with
VIR_DOMAIN_MIGRATE_MAX_SPEED_POSTCOPY flag, but in that case it should
only apply migration parameters and ignore capabilities.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
Notes:
Best viewed with --ignore-all-space
src/qemu/qemu_migration_params.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/src/qemu/qemu_migration_params.c b/src/qemu/qemu_migration_params.c
index 24e5368783..623193cf6c 100644
--- a/src/qemu/qemu_migration_params.c
+++ b/src/qemu/qemu_migration_params.c
@@ -778,14 +778,23 @@ qemuMigrationParamsApply(virQEMUDriverPtr driver,
if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
return -1;
- if (!(caps = qemuMigrationCapsToJSON(priv->migrationCaps, migParams->caps)))
- goto cleanup;
-
- if (virJSONValueArraySize(caps) > 0) {
- rc = qemuMonitorSetMigrationCapabilities(priv->mon, caps);
- caps = NULL;
- if (rc < 0)
+ if (asyncJob == QEMU_ASYNC_JOB_NONE) {
+ if (!virBitmapIsAllClear(migParams->caps)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("Migration capabilities can only be set by "
+ "a migration job"));
goto cleanup;
+ }
+ } else {
+ if (!(caps = qemuMigrationCapsToJSON(priv->migrationCaps, migParams->caps)))
+ goto cleanup;
+
+ if (virJSONValueArraySize(caps) > 0) {
+ rc = qemuMonitorSetMigrationCapabilities(priv->mon, caps);
+ caps = NULL;
+ if (rc < 0)
+ goto cleanup;
+ }
}
/* If QEMU is too old to support xbzrle-cache-size migration parameter,
--
2.21.0
5 years, 8 months
[libvirt] [PATCH] rpm: add dep on xfsprogs-devel for reflink support
by Daniel P. Berrangé
Support for XFS reflink clone was added in:
commit 8ed874b39b3c330bbcdff434e08995dbb4467285
Author: Julio Faracco <jcfaracco(a)gmail.com>
Date: Fri Jul 6 10:43:01 2018 -0300
storage: Rename btrfsCloneFile to support other filesystems.
commit 2e11298f938672c5430193277c98b9474a68b1fb
Author: Julio Faracco <jcfaracco(a)gmail.com>
Date: Fri Jul 6 10:43:00 2018 -0300
configure: Adding XFS library/headers check.
But these patches missed that the xfs/xfs.h header is not installed
unless you have xfsprogs-devel present.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
libvirt.spec.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 9beffba203..83b43f4ef6 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -326,6 +326,8 @@ BuildRequires: libiscsi-devel
BuildRequires: parted-devel
# For Multipath support
BuildRequires: device-mapper-devel
+# For XFS reflink clone support
+BuildRequires: xfsprogs-devel
%if %{with_storage_rbd}
BuildRequires: librados2-devel
BuildRequires: librbd1-devel
--
2.20.1
5 years, 8 months
[libvirt] [PATCH 1/2] security: aa-helper: nvidia rules for gl devices
by Christian Ehrhardt
Further testing with different devices showed that we need more rules
to drive gl backends with nvidia cards. Related denies look like:
apparmor="DENIED" operation="open"
name="/usr/share/egl/egl_external_platform.d/"
requested_mask="r"
apparmor="DENIED" operation="open"
name="/proc/modules"
requested_mask="r"
apparmor="DENIED" operation="open"
name="/proc/driver/nvidia/params"
requested_mask="r"
apparmor="DENIED" operation="mknod"
name="/dev/nvidiactl"
requested_mask="c"
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1817943
Signed-off-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com>
---
src/security/virt-aa-helper.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
index e9120213ff..13b507ff69 100644
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -1279,6 +1279,11 @@ get_files(vahControl * ctl)
virBufferAddLit(&buf, " \"/usr/share/drirc.d/{,*.conf}\" r,\n");
virBufferAddLit(&buf, " \"/etc/glvnd/egl_vendor.d/{,*}\" r,\n");
virBufferAddLit(&buf, " \"/usr/share/glvnd/egl_vendor.d/{,*}\" r,\n");
+ virBufferAddLit(&buf, " \"/usr/share/egl/egl_external_platform.d/\" r,\n");
+ virBufferAddLit(&buf, " \"/usr/share/egl/egl_external_platform.d/*\" r,\n");
+ virBufferAddLit(&buf, " \"/proc/modules\" r,\n");
+ virBufferAddLit(&buf, " \"/proc/driver/nvidia/params\" r,\n");
+ virBufferAddLit(&buf, " \"/dev/nvidiactl\" rw,\n");
virBufferAddLit(&buf, " # Probe DRI device attributes\n");
virBufferAddLit(&buf, " \"/dev/dri/\" r,\n");
virBufferAddLit(&buf, " \"/sys/devices/*/*/{uevent,vendor,device,subsystem_vendor,subsystem_device}\" r,\n");
--
2.17.1
5 years, 8 months
[libvirt] [PATCH for-4.0 v4 0/2] virtio: Provide version-specific variants of virtio PCI devices
by Eduardo Habkost
Existing modern-only device types are not being touched by v3, as
they don't need separate variants. However, I plan to implement
separate cleanups in the code that calls virtio_pci_force_virtio_1(),
first, and then propose additional changes (e.g. deprecating
disable-legacy and disable-modern in those device types).
Changes v3 -> v4:
* Trivial comment fixes (Cornelia Huck)
* Test code update (Caio Carrara)
Changes v2 -> v3:
* Split into two separate patches (type registration helper
and introduction of new types)
* Rewrote virtio_pci_types_register() completely:
* Replaced magic generation of type names with explicit fields in
VirtioPCIDeviceTypeInfo
* Removed modern_only field (not necessary anymore)
* Don't register a separate base type unless necessary
Changes v1 -> v2:
* Removed *-0.9 devices. Nobody will want to use them, if
transitional devices work with legacy drivers
(Gerd Hoffmann, Michael S. Tsirkin)
* Drop virtio version from name: rename -1.0-transitional to
-transitional (Michael S. Tsirkin)
* Renamed -1.0 to -non-transitional
* Don't add any extra variants to modern-only device types
(they don't need it)
* Fix typo on TYPE_VIRTIO_INPUT_HOST_PCI (crash reported by
Cornelia Huck)
* No need to change cast macros for modern-only devices
* Rename virtio_register_types() to virtio_pci_types_register()
Original patch description:
Many of the current virtio-*-pci device types actually represent
3 different types of devices:
* virtio 1.0 non-transitional devices
* virtio 1.0 transitional devices
* virtio 0.9 ("legacy device" in virtio 1.0 terminology)
That would be just an annoyance if it didn't break our device/bus
compatibility QMP interfaces. With this multi-purpose device
type, there's no way to tell management software that
transitional devices and legacy devices require a Conventional
PCI bus.
The multi-purpose device types would also prevent us from telling
management software what's the PCI vendor/device ID for them,
because their PCI IDs change at runtime depending on the bus
where they were plugged.
This patch adds separate device types for each of those virtio
device flavors:
* virtio-*-pci: the existing multi-purpose device types
* virtio-*-pci-transitional: virtio-1.0 device supporting legacy drivers
* virtio-*-pci-non-transitional: modern-only
Reference to previous discussion that originated this idea:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg558389.html
Eduardo Habkost (2):
virtio: Helper for registering virtio device types
virtio: Provide version-specific variants of virtio PCI devices
hw/virtio/virtio-pci.h | 78 +++++++--
hw/display/virtio-gpu-pci.c | 7 +-
hw/display/virtio-vga.c | 7 +-
hw/virtio/virtio-crypto-pci.c | 7 +-
hw/virtio/virtio-pci.c | 267 ++++++++++++++++++++++-------
tests/acceptance/virtio_version.py | 176 +++++++++++++++++++
6 files changed, 452 insertions(+), 90 deletions(-)
create mode 100644 tests/acceptance/virtio_version.py
--
2.18.0.rc1.1.g3f1ff2140
5 years, 8 months
[libvirt] [PATCH] libxl: Add support for max_grant_frame setting
by Jim Fehlig
Xen 4.10 introduced the max_grant_frames xl config setting, which
can be set globally in xl.conf(5) or per-domain in xl.cfg(5).
max_grant_frames specifies the maximum number of grant frames the
domain is allowed to have, which in turn controls the number of
pages the domain can share.
This patch adds support for setting max_grant_frames on a global
level in libxl.conf. Per-domain support via domXML can be provided
in a future patch.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
src/libxl/libvirtd_libxl.aug | 2 ++
src/libxl/libxl.conf | 8 ++++++++
src/libxl/libxl_conf.c | 9 +++++++++
src/libxl/libxl_conf.h | 2 ++
src/libxl/test_libvirtd_libxl.aug.in | 1 +
5 files changed, 22 insertions(+)
diff --git a/src/libxl/libvirtd_libxl.aug b/src/libxl/libvirtd_libxl.aug
index 58b9af3707..1c3e2719fc 100644
--- a/src/libxl/libvirtd_libxl.aug
+++ b/src/libxl/libvirtd_libxl.aug
@@ -29,6 +29,7 @@ module Libvirtd_libxl =
let keepalive_interval_entry = int_entry "keepalive_interval"
let keepalive_count_entry = int_entry "keepalive_count"
let nested_hvm_entry = bool_entry "nested_hvm"
+ let max_grant_frames_entry = int_entry "max_grant_frames"
(* Each entry in the config is one of the following ... *)
let entry = autoballoon_entry
@@ -36,6 +37,7 @@ module Libvirtd_libxl =
| keepalive_interval_entry
| keepalive_count_entry
| nested_hvm_entry
+ | max_grant_frames_entry
let comment = [ label "#comment" . del /#[ \t]*/ "# " . store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ]
let empty = [ label "#empty" . eol ]
diff --git a/src/libxl/libxl.conf b/src/libxl/libxl.conf
index 72825a71c5..12d7abeda6 100644
--- a/src/libxl/libxl.conf
+++ b/src/libxl/libxl.conf
@@ -49,3 +49,11 @@
# element.
# By default it is disabled.
#nested_hvm = 0
+
+# Xen domains can grant other domains access to its memory pages, which is
+# most commonly used for the operation of paravirtualized devices.
+# max_grant_frames was introduced in Xen 4.10 and can be used to specify a
+# default value for the maximum number of grant frames each domain started
+# by libvirt is allowed to have. The default value is 32.
+#
+#max_grant_frames = 32
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index c769050ff1..f57ffe1a01 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -393,6 +393,12 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
def->mem.cur_balloon = VIR_ROUND_UP(def->mem.cur_balloon, 1024);
b_info->max_memkb = virDomainDefGetMemoryInitial(def);
b_info->target_memkb = def->mem.cur_balloon;
+
+#ifdef LIBXL_HAVE_BUILDINFO_GRANT_LIMITS
+ if (cfg->max_grant_frames > 0)
+ b_info->max_grant_frames = cfg->max_grant_frames;
+#endif
+
if (hvm || pvh) {
if (caps &&
def->cpu && def->cpu->mode == (VIR_CPU_MODE_HOST_PASSTHROUGH)) {
@@ -1888,6 +1894,9 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
if (virConfGetValueBool(conf, "nested_hvm", &cfg->nested_hvm) < 0)
goto cleanup;
+ if (virConfGetValueUInt(conf, "max_grant_frames", &cfg->max_grant_frames) < 0)
+ goto cleanup;
+
ret = 0;
cleanup:
diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index fee94241af..985524f3eb 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -86,6 +86,8 @@ struct _libxlDriverConfig {
bool nested_hvm;
+ unsigned int max_grant_frames;
+
/* Once created, caps are immutable */
virCapsPtr caps;
diff --git a/src/libxl/test_libvirtd_libxl.aug.in b/src/libxl/test_libvirtd_libxl.aug.in
index 372a43f94a..754ddc10f6 100644
--- a/src/libxl/test_libvirtd_libxl.aug.in
+++ b/src/libxl/test_libvirtd_libxl.aug.in
@@ -7,3 +7,4 @@ module Test_libvirtd_libxl =
{ "keepalive_interval" = "5" }
{ "keepalive_count" = "5" }
{ "nested_hvm" = "0" }
+{ "max_grant_frames" = "32" }
--
2.20.1
5 years, 8 months
[libvirt] domXML modeling question
by Jim Fehlig
There have been a few requests [1][2] to support Xen's max_grant_frames setting
in libvirt domXML, but I'm not quite sure how to model it. The documentation [3]
on this setting states:
Specify the maximum number of grant frames the domain is allowed to have. This
value controls how many pages the domain is able to grant access to for other
domains, needed e.g. for the operation of paravirtualized devices. The default
is settable via xl.conf(5).
It smells of a <memtune> setting, e.g. the amount of memory a domain can share,
but doesn't map to any of the existing settings. A new subelement <shared_limit>
doesn't feel right. Does anyone suggest a better way of modeling max_grant_frames?
Another option I considered is setting the value based on number of PV devices,
but I think that flies in the face of libvirt's policy of not dictating policy.
Regardless of domain config modeling I can work on a driver-wide setting in
libxl.conf, similar to Xen's xl.conf(5) global.
Regards,
Jim
[1] https://www.redhat.com/archives/libvir-list/2018-April/msg00216.html
[2] https://www.redhat.com/archives/libvirt-users/2019-January/msg00011.html
[3]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.5.pod.i...
5 years, 8 months
[libvirt] [PATCH 0/4] Couple of patches about virsh completion
by Lin Ma
Lin Ma (4):
virsh: Only return active domain names for detach-device-alias
virsh: Add device name completion for target option of detach-disk
command
virsh-network: Introduce virshNetworkEventCallback to handle network
events
virsh: Add event name completion to 'network-event' command
tools/virsh-completer.c | 27 +++++++++++++++++++++++++++
tools/virsh-completer.h | 4 ++++
tools/virsh-domain.c | 3 ++-
tools/virsh-network.c | 18 +++++++++++++++---
tools/virsh-network.h | 8 ++++++++
5 files changed, 56 insertions(+), 4 deletions(-)
--
2.19.0
5 years, 8 months
[libvirt] [PATCH v1 00/15] Firmware auto selection
by Michal Privoznik
Libvirt allows specifying firmware for domains for quite some time now.
However, problem for mgmt applications is that they do not know which
firmware to chose as all they see are their paths and from that it's
impossible to tell whether one of them supports say secure boot.
This problem was addressed by qemu where Lazslo and Daniel created a
document, specification which describes metadata for each individual
firmware image. In the description (which itself is a JSON file for easy
machine parsing) then it's specified whether the firmware it's
describing supports secureboot, s3/s4 states, it it's bios or efi, and
so on.
These patches take advantage of that, and even though the description
files are not picked up by that many distributions yet, it allows users
to not care about putting specific firmware path into their domain XML.
It's as easy as:
<os firmware='efi'>
<loader secure='yes'/>
</os>
to have libvirt pick up OVMF image with secure enabled boot (and enabled
System Management Mode at the same time).
The metadata specification lives under
qemu.git/docs/interop/firmware.json and I highly recommend you go and
read it before reviewing (unless you're Laszlo or Daniel in which case
you already know what the document says).
As usual, you can find my patches at my github:
https://github.com/zippy2/libvirt/commits/firmware_v1
Michal Prívozník (15):
virmock: Initialize both symbols in VIR_MOCK_REAL_INIT_ALT
qemu_domain: Separate NVRAM VAR store file name generation
qemu_capabilities: Expose qemu <-> libvirt arch translators
virDomainLoaderDefParseXML: Allow loader path to be NULL
conf: Introduce VIR_DOMAIN_LOADER_TYPE_NONE
conf: Introduce firmware attribute to <os/>
qemu: Introduce basic skeleton for parsing firmware description
test: Introduce qemufirmwaretest
qemu_firmware: Introduce qemuFirmwareFetchConfigs
qemufirmwaretest: Test qemuFirmwareFetchConfigs()
qemu_firmware: Introduce qemuFirmwareFillDomain()
qemu_process: Call qemuFirmwareFillDomain
qemuDomainDefValidate: Don't require SMM if automatic firmware
selection enabled
qemu: Enable firmware autoselection
qemuxml2argvtest: Test os.firmware autoselection
docs/formatdomain.html.in | 22 +-
docs/schemas/domaincommon.rng | 12 +-
src/conf/domain_conf.c | 113 +-
src/conf/domain_conf.h | 15 +-
src/libvirt_private.syms | 2 +
src/qemu/Makefile.inc.am | 2 +
src/qemu/qemu_capabilities.c | 4 +-
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_command.c | 1 +
src/qemu/qemu_domain.c | 34 +-
src/qemu/qemu_domain.h | 4 +
src/qemu/qemu_firmware.c | 1285 +++++++++++++++++
src/qemu/qemu_firmware.h | 50 +
src/qemu/qemu_process.c | 5 +
tests/Makefile.am | 14 +-
tests/domaincapsschemadata/full.xml | 1 +
.../etc/qemu/firmware/40-ovmf-sb.json | 1 +
.../etc/qemu/firmware/60-ovmf.json | 0
.../user/.config/qemu/firmware/10-bios.json | 0
.../usr/share/qemu/firmware/40-bios.json | 35 +
.../usr/share/qemu/firmware/50-ovmf-sb.json | 36 +
.../usr/share/qemu/firmware/60-ovmf.json | 35 +
.../usr/share/qemu/firmware/70-aavmf.json | 35 +
tests/qemufirmwaretest.c | 129 ++
...arch64-os-firmware-efi.aarch64-latest.args | 37 +
.../aarch64-os-firmware-efi.xml | 30 +
.../os-firmware-bios.x86_64-latest.args | 39 +
tests/qemuxml2argvdata/os-firmware-bios.xml | 68 +
...os-firmware-efi-secboot.x86_64-latest.args | 42 +
.../os-firmware-efi-secboot.xml | 68 +
.../os-firmware-efi.x86_64-latest.args | 42 +
tests/qemuxml2argvdata/os-firmware-efi.xml | 68 +
tests/qemuxml2argvtest.c | 17 +
.../aarch64-os-firmware-efi.xml | 1 +
tests/qemuxml2xmloutdata/os-firmware-bios.xml | 1 +
.../os-firmware-efi-secboot.xml | 1 +
tests/qemuxml2xmloutdata/os-firmware-efi.xml | 1 +
tests/qemuxml2xmltest.c | 27 +
tests/virmock.h | 5 +-
39 files changed, 2255 insertions(+), 30 deletions(-)
create mode 100644 src/qemu/qemu_firmware.c
create mode 100644 src/qemu/qemu_firmware.h
create mode 120000 tests/qemufirmwaredata/etc/qemu/firmware/40-ovmf-sb.json
create mode 100644 tests/qemufirmwaredata/etc/qemu/firmware/60-ovmf.json
create mode 100644 tests/qemufirmwaredata/home/user/.config/qemu/firmware/10-bios.json
create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/40-bios.json
create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/50-ovmf-sb.json
create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/60-ovmf.json
create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/70-aavmf.json
create mode 100644 tests/qemufirmwaretest.c
create mode 100644 tests/qemuxml2argvdata/aarch64-os-firmware-efi.aarch64-latest.args
create mode 100644 tests/qemuxml2argvdata/aarch64-os-firmware-efi.xml
create mode 100644 tests/qemuxml2argvdata/os-firmware-bios.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/os-firmware-bios.xml
create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-secboot.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-secboot.xml
create mode 100644 tests/qemuxml2argvdata/os-firmware-efi.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/os-firmware-efi.xml
create mode 120000 tests/qemuxml2xmloutdata/aarch64-os-firmware-efi.xml
create mode 120000 tests/qemuxml2xmloutdata/os-firmware-bios.xml
create mode 120000 tests/qemuxml2xmloutdata/os-firmware-efi-secboot.xml
create mode 120000 tests/qemuxml2xmloutdata/os-firmware-efi.xml
--
2.19.2
5 years, 8 months
