- Devel - libvirt List Archives

[libvirt] VMX parser: limitation of numvcpus
by Pino Toscano 01 Jun '18

01 Jun '18

Hi Matthias, while testing the recent improvements I did in the VMX parser for CPU topology (see https://bugzilla.redhat.com/1568148) our QE Ming Xie set a guest in ESXi 5.5 to 7 cores. The result was the error triggered by the following code: /* vmx:numvcpus -> def:vcpus */ if (virVMXGetConfigLong(conf, "numvcpus", &numvcpus, 1, true) < 0) goto cleanup; if (numvcpus <= 0 || (numvcpus % 2 != 0 && numvcpus != 1)) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Expecting VMX entry 'numvcpus' to be an unsigned " "integer (1 or a multiple of 2) but found %lld"), numvcpus); goto cleanup; } Looking into the history, this check dates back to the initial addition of the esx driver, commit e2aeee6811917bc5ad28326c6a860ded39802a88. Considering the VMX format is proprietary of VMware, and officially undocumented, do you know remember why that limitation was added? Do you think removing it might break anything? Thanks, -- Pino Toscano

2 1

[libvirt] [PATCH for 4.4.0] news: Document two new features introduced in this release
by Michal Privoznik 01 Jun '18

01 Jun '18

The first feature is SCSI persistent reservation, the other is support for multihead screenshots. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/news.xml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index c45850f625..453ac1d02a 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -94,6 +94,25 @@ both new APIs consider capabilities of a specific hypervisor. </description> </change> + <change> + <summary> + Introduce SCSI persistent reservations support + </summary> + <description> + The QEMU driver gained support for qemu-pr-helper which enables + guests to issue SCSI commands for persistent reservation. + </description> + </change> + <change> + <summary> + qemu: Implement multiple screen support for virDomainScreenshot + </summary> + <description> + While the virDomainScreenshot API supported multihead video cards, + the implementation was missing. But now that QEMU implemented it + libvirt has done as well. + </description> + </change> </section> <section title="Improvements"> <change> -- 2.16.4

2 1

[libvirt] [PATCH 0/2] travis: Minor macOS improvements
by Andrea Bolognani 01 Jun '18

01 Jun '18

Andrea Bolognani (2): travis: Move PATH to macOS-specific environment travis: Install and use ccache on macOS .travis.yml | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) -- 2.17.0

2 3

[libvirt] [PATCHv2 0/7] qemu: add vhost-vsock-pci support
by Ján Tomko 01 Jun '18

01 Jun '18

v1: https://www.redhat.com/archives/libvir-list/2018-May/msg01517.html v2: * use <vsock> instead of <interface> * use <source> for the guest address * add <source auto> attribute and auto-assign the guest CID * fixed PCI address allocation https://bugzilla.redhat.com/show_bug.cgi?id=1291851 Ján Tomko (7): Introduce virDomainVsockDef Add privateData to virDomainVsockDef conf: introduce <vsock> element qemu: add private data for vsock Introduce QEMU_CAPS_DEVICE_VHOST_VSOCK util: create virvsock.c qemu: add support for vhost-vsock-pci configure.ac | 8 + docs/formatdomain.html.in | 20 ++ docs/schemas/domaincommon.rng | 29 +++ src/conf/domain_conf.c | 228 ++++++++++++++++++++- src/conf/domain_conf.h | 27 +++ src/libvirt_private.syms | 6 + src/qemu/qemu_alias.c | 16 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 45 ++++ src/qemu/qemu_domain.c | 42 ++++ src/qemu/qemu_domain.h | 9 + src/qemu/qemu_domain_address.c | 11 + src/qemu/qemu_driver.c | 6 + src/qemu/qemu_hotplug.c | 1 + src/qemu/qemu_process.c | 35 ++++ src/util/Makefile.inc.am | 2 + src/util/virvsock.c | 89 ++++++++ src/util/virvsock.h | 29 +++ tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + .../vhost-vsock-auto.x86_64-latest.args | 32 +++ tests/qemuxml2argvdata/vhost-vsock-auto.xml | 35 ++++ .../vhost-vsock.x86_64-latest.args | 32 +++ tests/qemuxml2argvdata/vhost-vsock.xml | 36 ++++ tests/qemuxml2argvtest.c | 14 ++ tests/qemuxml2xmloutdata/vhost-vsock-auto.xml | 36 ++++ tests/qemuxml2xmloutdata/vhost-vsock.xml | 1 + tests/qemuxml2xmltest.c | 3 + 41 files changed, 808 insertions(+), 1 deletion(-) create mode 100644 src/util/virvsock.c create mode 100644 src/util/virvsock.h create mode 100644 tests/qemuxml2argvdata/vhost-vsock-auto.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-vsock-auto.xml create mode 100644 tests/qemuxml2argvdata/vhost-vsock.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-vsock.xml create mode 100644 tests/qemuxml2xmloutdata/vhost-vsock-auto.xml create mode 120000 tests/qemuxml2xmloutdata/vhost-vsock.xml -- 2.16.1

3 21

[libvirt] [GSoC] Design ideas for implementing cleanup attribute
by Sukrit Bhatnagar 01 Jun '18

01 Jun '18

Hi, I am interested in implementing the GCC cleanup attribute for automatic resource freeing as part of GSoC'18. I have shared a proposal for the same. This mail is to discuss the code design for implementing it. Here are some of my ideas: This attribute requires a cleanup function that is called automatically when the corresponding variable goes out of scope. There are some functions whose logic can be reused: - Functions such as virCommandFree, virConfFreeList and virCgroupFree can be directly used as cleanup functions. They have parameter and return type valid for a cleanup function. - Functions such as virFileClose and virFileFclose need some additional consideration as they return a value. I think we can set some global variable in a separate source file (just like errno variable from errno.h). Then the value to be returned can be accessed globally. - Functions such as virDomainEventGraphicsDispose need an entirely new design. They are used as callbacks in object classes and passed as an argument in virClassNew. This would require making changes to virObjectUnref's code too. *This is the part I am not sure how to implement cleanup logic for.* Also, since the __attribute__((__cleanup__(anyfunc))) looks ugly, a macro like autoclean (ideas for macro name welcome!) can be used instead. As Martin pointed out in my proposal, for some types, this can be done right after typedef declarations, so that the type itself contains this attribute. Basically, at most places where VIR_FREE is used to release memory explicitly, the corresponding variable can use the attribute. The existing virFree function also can be reused as it takes void pointer as an argument and returns nothing. One of the exceptions to this will be those variables which are struct members. The cleanup of member has to be done when the enclosing struct variable is cleaned. I can create new files vircleanup.{c,h} for defining cleanup functions for types which do not have an existing cleanup/free function. This can be done separately for each driver supported. For example, cleanups pertaining to lxc driver will be in src/lxc/lxc_cleanup.c. Your suggestions are welcome. Thanks, Sukrit Bhatnagar

7 25

[libvirt] [jenkins-ci PATCH v3 0/3] Enable out-of-the-box parallel make
by Andrea Bolognani 01 Jun '18

01 Jun '18

Changes from [v2]: * now that libvirt-perl uses Module::Build and ExtUtils::MakeMaker support has been dropped, we don't need to special case any job, so revert back to [v1] and rebase on top of master because the original series doesn't apply anymore. Changes from [v1]: * turns out some versions of ExtUtils::MakeMaker output Makefiles that are not entirely compatible with parallel make, which forces us to introduce an exception in the relevant template and shuffle patches around. [v1] https://www.redhat.com/archives/libvir-list/2018-May/msg00732.html [v2] https://www.redhat.com/archives/libvir-list/2018-May/msg01070.html Andrea Bolognani (3): jobs: Enable parallel make everywhere guests: Set MAKEFLAGS for out-of-the-box parallel make jobs: Drop explicit parallel make usage guests/templates/bashrc | 2 ++ jobs/autotools.yaml | 10 +++++----- jobs/defaults.yaml | 1 - projects/libvirt.yaml | 4 ++-- projects/osinfo-db.yaml | 4 ++-- 5 files changed, 11 insertions(+), 10 deletions(-) -- 2.17.0

2 4

[libvirt] [PATCH v2] util: Loop through all resolved addresses in virNetSocketNewListenTCP
by Olaf Hering 01 Jun '18

01 Jun '18

Currently virNetSocketNewListenTCP bails out early under the following conditions: - the hostname resolves to at least one IPv4 and at least one IPv6 address - the local interfaces have that one IPv4 address assigned, but not any of the IPv6 addresses - the local interfaces have just IPv6 link-local addresses In this case the resolver returns not only the IPv4 addresses but also IPv6. Binding the IPv6 address will obviously fail. But this terminates the entire loop, even if binding to IPv4 succeeded. To fix this error, just keep going and loop through all returned addresses. In case none of the attempts to bind to some address succeeded, try to report the appropriate error. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> --- v2: whitespace fixes, as suggested by John Ferlan src/rpc/virnetsocket.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index 7087abec9c..60a7187348 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -382,11 +382,8 @@ int virNetSocketNewListenTCP(const char *nodename, #endif if (bind(fd, runp->ai_addr, runp->ai_addrlen) < 0) { - if (errno != EADDRINUSE) { - virReportSystemError(errno, "%s", _("Unable to bind to port")); - goto error; - } - addrInUse = true; + if (errno == EADDRINUSE) + addrInUse = true; VIR_FORCE_CLOSE(fd); runp = runp->ai_next; continue; @@ -409,14 +406,14 @@ int virNetSocketNewListenTCP(const char *nodename, fd = -1; } - if (nsocks == 0 && familyNotSupported) { - virReportSystemError(EAFNOSUPPORT, "%s", _("Unable to bind to port")); - goto error; - } - - if (nsocks == 0 && - addrInUse) { - virReportSystemError(EADDRINUSE, "%s", _("Unable to bind to port")); + if (nsocks == 0) { + if (familyNotSupported) + errno = EAFNOSUPPORT; + else if (addrInUse) + errno = EADDRINUSE; + else + errno = EDESTADDRREQ; + virReportSystemError(errno, "%s", _("Unable to bind to port")); goto error; }

2 1

[libvirt] [RFC PATCH 0/9] qemu: add vhost-vsock-pci support
by Ján Tomko 01 Jun '18

01 Jun '18

@Stefan, please take a look at the docs/ changes in patch 6 Add <interface type='vsock'>, mapping to vhost-vsock-pci Missing: hotplug support Similar to vhost-net, we cannot apply a SELinux label on the file descriptor, so an adjustment of the policy will probably be needed to make it work in enforcing mode. https://bugzilla.redhat.com/show_bug.cgi?id=1291851 Ján Tomko (9): conf: split interface target element condition qemu: prepare for missing interface model Introduce virDomainNetDefNew Add privateData to virDomainNetDef qemu: add private data for interfaces conf: add interface type vsock Introduce QEMU_CAPS_DEVICE_VHOST_VSOCK Introduce virNetDevVsockSetGuestCid qemu: implement vhost-vsock-pci support configure.ac | 8 ++ docs/formatdomain.html.in | 15 ++++ docs/schemas/domaincommon.rng | 14 ++++ src/bhyve/bhyve_parse_command.c | 2 +- src/conf/domain_conf.c | 85 ++++++++++++++++++---- src/conf/domain_conf.h | 8 ++ src/conf/netdev_bandwidth_conf.h | 1 + src/libvirt_private.syms | 2 + src/libxl/libxl_conf.c | 1 + src/lxc/lxc_controller.c | 1 + src/lxc/lxc_driver.c | 3 + src/lxc/lxc_process.c | 1 + src/openvz/openvz_conf.c | 4 +- src/qemu/qemu_capabilities.c | 3 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 43 +++++++++-- src/qemu/qemu_domain.c | 47 ++++++++++++ src/qemu/qemu_domain.h | 13 ++++ src/qemu/qemu_domain_address.c | 6 +- src/qemu/qemu_hotplug.c | 3 + src/qemu/qemu_interface.c | 33 +++++++++ src/qemu/qemu_interface.h | 4 + src/qemu/qemu_parse_command.c | 2 +- src/qemu/qemu_process.c | 6 ++ src/uml/uml_conf.c | 5 ++ src/util/virnetdev.c | 30 ++++++++ src/util/virnetdev.h | 4 + src/vbox/vbox_common.c | 2 +- src/vmx/vmx.c | 3 +- src/xenconfig/xen_common.c | 3 +- src/xenconfig/xen_sxpr.c | 3 +- tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + .../vhost-vsock.x86_64-latest.args | 32 ++++++++ tests/qemuxml2argvdata/vhost-vsock.xml | 36 +++++++++ tests/qemuxml2argvtest.c | 15 ++++ tests/qemuxml2xmloutdata/vhost-vsock.xml | 1 + tests/qemuxml2xmltest.c | 2 + tools/virsh-domain.c | 1 + 51 files changed, 425 insertions(+), 32 deletions(-) create mode 100644 tests/qemuxml2argvdata/vhost-vsock.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-vsock.xml create mode 120000 tests/qemuxml2xmloutdata/vhost-vsock.xml -- 2.16.1

2 12

[libvirt] [PATCH] util: storage: remove virStorageSource->tlsVerify
by Peter Krempa 01 Jun '18

01 Jun '18

Disks are client-only so we don't need to have this variable. We also always pass false for 'isListen' to qemuBuildTLSx509BackendProps for all disk-related code-paths. --- This applies on top of my branch collecting all ACKed postings of recent blockdev-related work. Current version can be fetched by: git fetch git://pipo.sk/pipo/libvirt.git blockdev-staging src/qemu/qemu_command.c | 2 +- src/qemu/qemu_domain.c | 2 -- src/qemu/qemu_hotplug.c | 3 +-- src/util/virstoragefile.c | 1 - src/util/virstoragefile.h | 1 - 5 files changed, 2 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 26e61f26f4..c75595ca6d 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -774,7 +774,7 @@ qemuBuildDiskSrcTLSx509CommandLine(virCommandPtr cmd, return 0; return qemuBuildTLSx509CommandLine(cmd, src->tlsCertdir, - false, src->tlsVerify, + false, true, NULL, src->tlsAlias, qemuCaps); } diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 4368e9be35..873bcec50d 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -9928,8 +9928,6 @@ qemuProcessPrepareStorageSourceTLSVxhs(virStorageSourcePtr src, if (src->haveTLS == VIR_TRISTATE_BOOL_YES) { if (VIR_STRDUP(src->tlsCertdir, cfg->vxhsTLSx509certdir) < 0) return -1; - - src->tlsVerify = true; } return 0; diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index c656409eaa..2f76c048aa 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -164,8 +164,7 @@ qemuDomainAddDiskSrcTLSObject(virQEMUDriverPtr driver, if (qemuDomainGetTLSObjects(priv->qemuCaps, NULL, src->tlsCertdir, - false, - src->tlsVerify, + false, true, src->tlsAlias, &tlsProps, NULL) < 0) goto cleanup; diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 54de2c1c30..10fe0f201a 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -2171,7 +2171,6 @@ virStorageSourceCopy(const virStorageSource *src, ret->shared = src->shared; ret->haveTLS = src->haveTLS; ret->tlsFromConfig = src->tlsFromConfig; - ret->tlsVerify = src->tlsVerify; ret->detected = src->detected; ret->debugLevel = src->debugLevel; ret->debug = src->debug; diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h index 1631c4cf66..4591e6e213 100644 --- a/src/util/virstoragefile.h +++ b/src/util/virstoragefile.h @@ -310,7 +310,6 @@ struct _virStorageSource { * certificate directory with listen and verify bools. */ char *tlsAlias; char *tlsCertdir; - bool tlsVerify; bool detected; /* true if this entry was not provided by the user */ -- 2.16.2

2 1

[libvirt] [RFC PATCH 0/9] tests: Record commands used to gather capability replies
by Peter Krempa 01 Jun '18

01 Jun '18

De-confusify the 'replies' files for human usage by recording which commands were used for gathering given block. Additionally this tests that the commands emitted by libvirt are as recorded. This series is in RFC state, since it creates some churn in the capability files and also 'tests/qemucapsfixreplies' will no longer work. Patch 8 contains the changed files for ease of review and patch 9 contains the tool used to regenerate them from the current state. Peter Krempa (9): qemu: monitor: Add possibility to reset command sequence in tests tests: qemumonitor: Simplify handling of end of file in full file test tests: qemumonitor: Optimize control flow when concatenating replies tests: qemucapsprobemock: Simplify and extract skipping of empty lines tests: qemucapsprobemock: Fail if JSON reply from qemu can't be reformatted tests: qemucapsprobemock: Prepare 'qemucapsprobe' for the new format tests: qemucapabilities: Test commands used to query capabilities FIXUP: Tweak capability files to conform to the new approach DO_NOT_APPLY: HACK: Regenerate qemucapabilitiestest data fix-files.sh | 1 + src/qemu/qemu_monitor.c | 11 + src/qemu/qemu_monitor_priv.h | 31 + tests/Makefile.am | 1 + .../qemucapabilitiesdata/caps_1.5.3.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_1.6.0.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_1.7.0.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.1.1.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 2 +- .../caps_2.10.0.aarch64.replies | 319 +++++- tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.10.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.10.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 2 +- .../caps_2.10.0.x86_64.replies | 1120 ++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.11.0.s390x.replies | 350 +++++- tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 2 +- .../caps_2.12.0.aarch64.replies | 328 +++++- tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.12.0.ppc64.replies | 331 +++++- tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.12.0.s390x.replies | 358 +++++- tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 +- .../caps_2.12.0.x86_64.replies | 1173 +++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies | 341 +++++- tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 2 +- .../caps_2.6.0.aarch64.replies | 319 +++++- tests/qemucapabilitiesdata/caps_2.6.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.6.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.7.0.s390x.replies | 306 ++++- tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.8.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.8.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.x86_64.replies | 1120 ++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 2 +- tests/qemucapabilitiestest.c | 17 +- tests/qemucapsprobemock.c | 77 +- tests/qemumonitortestutils.c | 52 +- 57 files changed, 10564 insertions(+), 385 deletions(-) create mode 100755 fix-files.sh create mode 100644 src/qemu/qemu_monitor_priv.h -- 2.16.2

1 10