- Devel - libvirt List Archives

[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

[libvirt] Why does vnc show blackscreen after using mstsc to connect to a windows vm with a nvidia gpu passtrough
by Wu Zongyong 01 Jun '18

01 Jun '18

Hi, As the title says, VNC inside a windows virtual machine doesn’t work after I try to use mstsc to access the vm with a gpu passthrough. It seems that the scenario is normal, but could someone tell me something deeply about the reason why vnc shows blackscreen? Thanks.

1 0

[libvirt] Question about using cpu mode "host-model" while providing a cpu model name
by Collin Walling 31 May '18

31 May '18

Hi I have noticed something that may be misconstrued regarding the libvirt domain xml format for defining a cpu model. There seems to be a misalignment where the libvirt documentation states something that is not supported, but libvirt itself gives no clear indication of such. This is regarding the cpu mode "host-model" and providing a cpu model name between the <model> tags. >From the libvirt docs under header "CPU model and topology" paragraph "cpu" subparagraph "host-model", the following rule is defined (bolded or between asterisks): "... The match attribute can't be used in this mode. *Specifying CPU model is not supported* either, but model's fallback attribute may still be used. ..." https://libvirt.org/formatdomain.html#elementsCPU The above rule reads as "if mode is 'host-model' (and the architecture is not PowerPC) then specifying a model name should not be allowed". However, this is not the observed behavior. For example, I can define and start a guest with the following xml snippet without any issues: <cpu mode='host-model'> <model>cpu-name</model> </cpu> Which seems to contradict what the documentation states. This issue was reported by a colleague of mine who was confused by the cpu features that were available to a guest when host-model and a model name are provided. Personally, I tend to err on the side of providing host-model and a cpu-model-name being mutually exclusive. I've attempted to find a solution to this problem myself by looking at virCPUDefParseXML, but the fact that PowerPC exists as an exception and we do not know the architecture when parsing a guest cpu xml makes minimal code changes challenging. If we want to make changes to the code, then I imagine that the ideal solution would revolve around only allowing <model>cpu-name</model> to be valid iff the cpu mode is set to "custom". Otherwise some clarity on the documentation would suffice. Something like "A CPU model specified in the domain xml will be ignored." Thoughts? Thank you for your time. -- Respectfully, - Collin Walling

5 6

[libvirt] [python PATCH] Add support for virConnectBaselineHypervisorCPU
by Jiri Denemark 31 May '18

31 May '18

The python bindings for this API cannot be generated because are generator is not capable of handling string arrays (char **) parameters. https://bugzilla.redhat.com/show_bug.cgi?id=1584676 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- generator.py | 1 + libvirt-override-api.xml | 11 ++++++++ libvirt-override.c | 60 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 72 insertions(+) diff --git a/generator.py b/generator.py index a0fc720..b7d96a1 100755 --- a/generator.py +++ b/generator.py @@ -488,6 +488,7 @@ skip_impl = ( 'virDomainGetPerfEvents', 'virDomainSetPerfEvents', 'virDomainGetGuestVcpus', + 'virConnectBaselineHypervisorCPU', ) lxc_skip_impl = ( diff --git a/libvirt-override-api.xml b/libvirt-override-api.xml index b63a403..36d3577 100644 --- a/libvirt-override-api.xml +++ b/libvirt-override-api.xml @@ -717,5 +717,16 @@ <arg name='flags' type='unsigned int' info='extra flags; not used yet, so callers should always pass 0'/> <return type='int' info="dictionary of vcpu data returned by the guest agent"/> </function> + <function name='virConnectBaselineHypervisorCPU' file='python'> + <info>Computes the most feature-rich CPU which is compatible with all given CPUs and can be provided by the specified hypervisor.</info> + <return type='char *' info='XML description of the computed CPU or NULL on error.'/> + <arg name='conn' type='virConnectPtr' info='pointer to the hypervisor connection'/> + <arg name='emulator' type='const char *' info='path to the emulator binary'/> + <arg name='arch' type='const char *' info='CPU architecture'/> + <arg name='machine' type='const char *' info='machine type'/> + <arg name='virttype' type='const char *' info='virtualization type'/> + <arg name='xmlCPUs' type='const char **' info='array of XML descriptions of CPUs'/> + <arg name='flags' type='unsigned int' info='bitwise-OR of virConnectBaselineCPUFlags'/> + </function> </symbols> </api> diff --git a/libvirt-override.c b/libvirt-override.c index b4c1529..1c95c18 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -9708,6 +9708,63 @@ libvirt_virStreamRecvFlags(PyObject *self ATTRIBUTE_UNUSED, #endif /* LIBVIR_CHECK_VERSION(3, 4, 0) */ +#if LIBVIR_CHECK_VERSION(4, 4, 0) +static PyObject * +libvirt_virConnectBaselineHypervisorCPU(PyObject *self ATTRIBUTE_UNUSED, + PyObject *args) +{ + virConnectPtr conn; + PyObject *pyobj_conn; + char *emulator; + char *arch; + char *machine; + char *virttype; + PyObject *list; + unsigned int flags; + char **xmlCPUs = NULL; + int ncpus = 0; + size_t i; + char *cpu; + PyObject *ret = NULL; + + if (!PyArg_ParseTuple(args, (char *)"OzzzzOI:virConnectBaselineHypervisorCPU", + &pyobj_conn, &emulator, &arch, &machine, &virttype, + &list, &flags)) + return NULL; + + conn = (virConnectPtr) PyvirConnect_Get(pyobj_conn); + + if (PyList_Check(list)) { + ncpus = PyList_Size(list); + if (VIR_ALLOC_N(xmlCPUs, ncpus) < 0) + return PyErr_NoMemory(); + + for (i = 0; i < ncpus; i++) { + if (libvirt_charPtrUnwrap(PyList_GetItem(list, i), + &(xmlCPUs[i])) < 0 || + !xmlCPUs[i]) + goto cleanup; + } + } + + LIBVIRT_BEGIN_ALLOW_THREADS; + cpu = virConnectBaselineHypervisorCPU(conn, emulator, arch, machine, virttype, + (const char **)xmlCPUs, ncpus, flags); + LIBVIRT_END_ALLOW_THREADS; + + ret = libvirt_constcharPtrWrap(cpu); + + cleanup: + for (i = 0; i < ncpus; i++) + VIR_FREE(xmlCPUs[i]); + VIR_FREE(xmlCPUs); + VIR_FREE(cpu); + + return ret; +} +#endif /* LIBVIR_CHECK_VERSION(4, 4, 0) */ + + /************************************************************************ * * * The registration stuff * @@ -9941,6 +9998,9 @@ static PyMethodDef libvirtMethods[] = { {(char *) "virStreamSendHole", libvirt_virStreamSendHole, METH_VARARGS, NULL}, {(char *) "virStreamRecvFlags", libvirt_virStreamRecvFlags, METH_VARARGS, NULL}, #endif /* LIBVIR_CHECK_VERSION(3, 4, 0) */ +#if LIBVIR_CHECK_VERSION(4, 4, 0) + {(char *) "virConnectBaselineHypervisorCPU", libvirt_virConnectBaselineHypervisorCPU, METH_VARARGS, NULL}, +#endif /* LIBVIR_CHECK_VERSION(4, 4, 0) */ {NULL, NULL, 0, NULL} }; -- 2.17.0

2 1

[libvirt] [PATCH 00/13] qemu: Refactor how we handle 'object's on the monitor
by Peter Krempa 31 May '18

31 May '18

This applies on top of the tls/secret alias refactoring series I've posted earlier today: https://www.redhat.com/archives/libvir-list/2018-May/msg02174.html The main idea is to clarify the lifecycle of the objects used on the monitor and clean up the code using it. Peter Krempa (13): qemu: command: Fix name of qemuBuildMemoryBackendStr qemu: monitor: Rename qemuMonitorAddObject to qemuMonitorAddObjectType qemu: Rename virQEMUBuildObjectCommandlineFromJSON qemu: monitor: Add better APIs for adding of objects to qemu util: qemu: Introduce helper for formatting command line from new object props qemu: hotplug: Refactor PR props formatting to use qemuMonitorCreateObjectProps qemu: hotplug: Refactor RNG props formatting to use qemuMonitorCreateObjectProps qemu: hotplug: Refactor memory props formatting to qemuMonitorCreateObjectProps qemu: hotplug: Refactor shmem props formatting to qemuMonitorCreateObjectProps qemu: hotplug: Refactor tls-credential props formatting to qemuMonitorCreateObjectProps qemu: hotplug: Refactor 'secret' props formatting to qemuMonitorCreateObjectProps qemu: Convert iothread hotplug to qemuMonitorCreateObjectProps qemu: Delete old unused code for adding objects to qemu src/qemu/qemu_command.c | 300 +++++++++++++++++---------------------- src/qemu/qemu_command.h | 18 +-- src/qemu/qemu_driver.c | 14 +- src/qemu/qemu_hotplug.c | 148 +++++++------------ src/qemu/qemu_hotplug.h | 3 +- src/qemu/qemu_migration_params.c | 5 +- src/qemu/qemu_monitor.c | 98 +++++++++++-- src/qemu/qemu_monitor.h | 14 +- src/qemu/qemu_monitor_json.c | 15 +- src/qemu/qemu_monitor_json.h | 2 - src/util/virqemu.c | 40 ++++-- src/util/virqemu.h | 5 +- 12 files changed, 336 insertions(+), 326 deletions(-) -- 2.16.2

2 26

[libvirt] [PATCH v3 0/4] capabilities: Provide info about host IOMMU
by Filip Alac 31 May '18

31 May '18

Filip Alac (4): virutil: Introduce virHostHasIOMMU qemu: hostdev: Refactor code capabilities: Extend capabilities with iommu_support docs: news: Explain iommu_support improvement docs/news.xml | 8 +++++ docs/schemas/capability.rng | 13 +++++++++ src/conf/capabilities.c | 9 ++++++ src/conf/capabilities.h | 3 ++ src/libvirt_private.syms | 2 ++ src/qemu/qemu_capabilities.c | 3 ++ src/qemu/qemu_hostdev.c | 29 +++---------------- src/test/test_driver.c | 2 ++ src/util/virutil.c | 28 ++++++++++++++++++ src/util/virutil.h | 2 ++ tests/qemucaps2xmldata/all_1.6.0-1.xml | 1 + .../nodisksnapshot_1.6.0-1.xml | 1 + .../vircaps2xmldata/vircaps-aarch64-basic.xml | 1 + .../vircaps2xmldata/vircaps-x86_64-basic.xml | 1 + .../vircaps2xmldata/vircaps-x86_64-caches.xml | 1 + .../vircaps-x86_64-resctrl-cdp.xml | 1 + .../vircaps-x86_64-resctrl-skx-twocaches.xml | 1 + .../vircaps-x86_64-resctrl-skx.xml | 1 + .../vircaps-x86_64-resctrl.xml | 1 + 19 files changed, 83 insertions(+), 25 deletions(-) -- 2.17.0

2 7

[libvirt] [PATCH] qemu: hotplug: Fix detach of disk with managed persistent reservations
by Peter Krempa 31 May '18

31 May '18

In commit 8bebb2b735d I've refactored how the detach of disk with a managed persistent reservations object is handled. After the commit if any disk with a managed PR object would be removed libvirt would also attempt to remove the shared 'pr-manager-helper' object potentially used by other disks. Thankfully this should not have practical impact as qemu should reject deletion of the object if it was still used and the rest of the code is correct. Fix this by removing the disk from the definition earlier and checking if the shared/managed pr-manager-helper object is still needed. This basically splits the detach code for the managed PR object from the unmanaged ones. The same separation will follow for the attachment code as well as it greatly simplifies -blockdev support for this. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_hotplug.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index b4bbe62c75..a14281203a 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3839,6 +3839,8 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, char *drivestr; char *objAlias = NULL; char *encAlias = NULL; + bool prManaged = priv->prDaemonRunning; + bool prUsed = false; VIR_DEBUG("Removing disk %s from domain %p %s", disk->info.alias, vm, vm->def->name); @@ -3876,6 +3878,16 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, } } + for (i = 0; i < vm->def->ndisks; i++) { + if (vm->def->disks[i] == disk) { + virDomainDiskRemove(vm->def, i); + break; + } + } + + /* check if the last disk with managed PR was just removed */ + prUsed = virDomainDefHasManagedPR(vm->def); + qemuDomainObjEnterMonitor(driver, vm); qemuMonitorDriveDel(priv->mon, drivestr); @@ -3892,12 +3904,16 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, VIR_FREE(encAlias); /* If it fails, then so be it - it was a best shot */ - if (disk->src->pr) + if (disk->src->pr && + !virStoragePRDefIsManaged(disk->src->pr)) ignore_value(qemuMonitorDelObject(priv->mon, disk->src->pr->mgralias)); if (disk->src->haveTLS) ignore_value(qemuMonitorDelObject(priv->mon, disk->src->tlsAlias)); + if (prManaged && !prUsed) + ignore_value(qemuMonitorDelObject(priv->mon, qemuDomainGetManagedPRAlias())); + if (qemuDomainObjExitMonitor(driver, vm) < 0) return -1; @@ -3906,16 +3922,7 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, event = virDomainEventDeviceRemovedNewFromObj(vm, disk->info.alias); qemuDomainEventQueue(driver, event); - for (i = 0; i < vm->def->ndisks; i++) { - if (vm->def->disks[i] == disk) { - virDomainDiskRemove(vm->def, i); - break; - } - } - - /* check if the last disk with managed PR was just removed */ - if (priv->prDaemonRunning && - !virDomainDefHasManagedPR(vm->def)) + if (prManaged && !prUsed) qemuProcessKillManagedPRDaemon(vm); qemuDomainReleaseDeviceAddress(vm, &disk->info, src); -- 2.16.2

2 1

[libvirt] [RFC 0/4] add automatic cleanup functionality in some files
by Sukrit Bhatnagar 31 May '18

31 May '18

This series of patches aim at augmenting our discussion about the design for implementing the cleanup attribute. A set of macros have been added at the end of viralloc.h A few files have been modified to use the newly created macros. Sukrit Bhatnagar (4): add macros for implementing automatic cleanup functionality add automatic cleanup support in src/util/virarptable.c add automatic cleanup support in src/util/virauthconfig.c add automatic cleanup support in src/util/virauth.c src/util/viralloc.h | 69 ++++++++++++++++++++++++++++++++++++++++++++++++ src/util/virarptable.c | 9 ++----- src/util/virauth.c | 66 +++++++++++++++++---------------------------- src/util/virauthconfig.c | 34 +++++++++--------------- src/util/virauthconfig.h | 3 +++ 5 files changed, 110 insertions(+), 71 deletions(-) -- 1.8.3.1

3 10

[libvirt] ANNOUNCE: virt-bootstrap 1.1.0 released
by Cedric Bosdonnat 31 May '18

31 May '18

I'm happy to announce the release of virt-bootstrap 1.1.0! virt-bootstrap is a tool providing an easy way to setup the root file system for libvirt-based containers. The release can be downloaded from: http://virt-manager.org/download/ This release includes: - safe_untar: check for permissions to set attribs (Radostin Stoyanov) - docker source, support blobs without .tar extension (Radostin Stoyanov) - docker-source, preserve extended file attributes (Radostin Stoyanov) - docker-source, get list of layers without `--raw` (Radostin Stoyanov) - docker-source, void skopeo copy in cache (Radostin Stoyanov) - Show error when guestfs-python or skopeo is not installed (Radostin Stoyanov) - pylint cleanups (Radostin Stoyanov) Thanks to everyone who has contributed to this release through testing, bug reporting, submitting patches, and otherwise sending in feedback! Thanks, -- Cédric

1 0

[libvirt] [PATCH] testUpdateQEMUCaps: Don't leak host cpuData
by Michal Privoznik 31 May '18

31 May '18

When preparing qemuCaps for test cases the following is happening: qemuTestParseCapabilitiesArch() is called, which calls virQEMUCapsLoadCache() which in turn calls virQEMUCapsInitHostCPUModel() which sets qemuCaps->kvmCPU and qemuCaps->tcgCPU. But then the code tries to update the capabilities: testCompareXMLToArgv() calls testUpdateQEMUCaps() which calls virQEMUCapsInitHostCPUModel() again overwriting previously allocated memory. The solution is to free host cpuData in testUpdateQEMUCaps(). Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Technically this is v2 of [1] but since it implements completely different approach I'm sending it as v1. 1: https://www.redhat.com/archives/libvir-list/2018-May/msg02260.html src/qemu/qemu_capabilities.c | 21 +++++++++++++++++++-- src/qemu/qemu_capspriv.h | 4 ++++ tests/qemuxml2argvtest.c | 3 +++ 3 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index e2e76e4dd8..ea1ff520d8 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -1516,12 +1516,19 @@ virQEMUCapsHostCPUDataCopy(virQEMUCapsHostCPUDataPtr dst, static void -virQEMUCapsHostCPUDataClear(virQEMUCapsHostCPUDataPtr cpuData) +virQEMUCapsHostCPUDataClearHostCPU(virQEMUCapsHostCPUDataPtr cpuData) { - qemuMonitorCPUModelInfoFree(cpuData->info); virCPUDefFree(cpuData->reported); virCPUDefFree(cpuData->migratable); virCPUDefFree(cpuData->full); +} + + +static void +virQEMUCapsHostCPUDataClear(virQEMUCapsHostCPUDataPtr cpuData) +{ + qemuMonitorCPUModelInfoFree(cpuData->info); + virQEMUCapsHostCPUDataClearHostCPU(cpuData); memset(cpuData, 0, sizeof(*cpuData)); } @@ -2834,6 +2841,16 @@ virQEMUCapsNewHostCPUModel(void) } +void +virQEMUCapsFreeHostCPUModel(virQEMUCapsPtr qemuCaps, + virDomainVirtType type) +{ + virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type); + + virQEMUCapsHostCPUDataClearHostCPU(cpuData); +} + + void virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps, virArch hostArch, diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h index 0199501c93..fea039ef3a 100644 --- a/src/qemu/qemu_capspriv.h +++ b/src/qemu/qemu_capspriv.h @@ -56,6 +56,10 @@ void virQEMUCapsSetArch(virQEMUCapsPtr qemuCaps, virArch arch); +void +virQEMUCapsFreeHostCPUModel(virQEMUCapsPtr qemuCaps, + virDomainVirtType type); + void virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps, virArch hostArch, diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index a6a40e273e..61c7ae59aa 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -388,6 +388,9 @@ testUpdateQEMUCaps(const struct testInfo *info, if (testAddCPUModels(info->qemuCaps, info->skipLegacyCPUs) < 0) goto cleanup; + virQEMUCapsFreeHostCPUModel(info->qemuCaps, VIR_DOMAIN_VIRT_KVM); + virQEMUCapsFreeHostCPUModel(info->qemuCaps, VIR_DOMAIN_VIRT_QEMU); + virQEMUCapsInitHostCPUModel(info->qemuCaps, caps->host.arch, VIR_DOMAIN_VIRT_KVM); virQEMUCapsInitHostCPUModel(info->qemuCaps, caps->host.arch, -- 2.16.4

2 1