External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-01 02:41:14 +00:00
Code Issues Packages Projects Releases Wiki Activity
6af8417415
libvirt/src/qemu/qemu_capabilities.c

5411 lines
162 KiB
C
Raw Normal View History

Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
/*
* qemu_capabilities.c: QEMU capabilities generation
*
qemu: add capability check for memballoon 'deflate-on-oom' feature Add appropriate capability check and new virQEMUCaps flag for the new virtio balloon feature. QEMU commit with the complete feature description: http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0dc14d841b80
2016-01-08 10:45:06 +00:00
* Copyright (C) 2006-2016 Red Hat, Inc.
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
* Copyright (C) 2006 Daniel P. Berrange
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
maint: fix up copyright notice inconsistencies https://www.gnu.org/licenses/gpl-howto.html recommends that the 'If not, see <url>.' phrase be a separate sentence. * tests/securityselinuxhelper.c: Remove doubled line. * tests/securityselinuxtest.c: Likewise. * globally: s/; If/. If/
2012-09-20 22:30:55 +00:00
* License along with this library. If not, see
Desert the FSF address in copyright Per the FSF address could be changed from time to time, and GNU recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html) You should have received a copy of the GNU General Public License along with Foobar. If not, see <http://www.gnu.org/licenses/>. This patch removes the explicit FSF address, and uses above instead (of course, with inserting 'Lesser' before 'General'). Except a bunch of files for security driver, all others are changed automatically, the copyright for securify files are not complete, that's why to do it manually: src/security/security_selinux.h src/security/security_driver.h src/security/security_selinux.c src/security/security_apparmor.h src/security/security_apparmor.c src/security/security_driver.c
2012-07-21 10:06:23 +00:00
* <http://www.gnu.org/licenses/>.
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
*
* Author: Daniel P. Berrange <berrange@redhat.com>
*/
#include <config.h>
#include "qemu_capabilities.h"
Rename memory.{c,h} to viralloc.{c,h}
2012-12-12 18:06:53 +00:00
#include "viralloc.h"
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
#include "vircrypto.h"
Rename logging.{c,h} to virlog.{c,h}
2012-12-12 17:59:27 +00:00
#include "virlog.h"
Rename virterror.c virterror_internal.h to virerror.{c,h}
2012-12-13 18:21:53 +00:00
#include "virerror.h"
build: rename files.h to virfile.h In preparation for a future patch adding new virFile APIs. * src/util/files.h, src/util/files.c: Move... * src/util/virfile.h, src/util/virfile.c: ...here, and rename functions to virFile prefix. Macro names are intentionally left alone. * *.c: All '#include "files.h"' uses changed. * src/Makefile.am (UTIL_SOURCES): Reflect rename. * cfg.mk (exclude_file_name_regexp--sc_prohibit_close): Likewise. * src/libvirt_private.syms: Likewise. * docs/hacking.html.in: Likewise. * HACKING: Regenerate.
2011-07-19 18:32:58 +00:00
#include "virfile.h"
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
#include "virfilecache.h"
qemu: Kill processes used for QMP caps probing Since libvirt switched to QMP capabilities probing recently, it starts QEMU process used for this probing with -daemonize, which means virCommandAbort can no longer reach these processes. As a result of that, restarting libvirtd will leave several new QEMU processes behind. Let's use QEMU's -pidfile and use it to kill the process when QMP caps probing is done.
2012-10-02 08:59:56 +00:00
#include "virpidfile.h"
#include "virprocess.h"
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
#include "cpu/cpu.h"
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
#include "cpu/cpu_x86.h"
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
#include "domain_conf.h"
Rename command.{c,h} to vircommand.{c,h}
2012-12-12 16:27:01 +00:00
#include "vircommand.h"
Rename bitmap.{c,h} to virbitmap.{c,h} Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-04 11:56:32 +00:00
#include "virbitmap.h"
Move suspend capabilities APIs out of util.h into virnodesuspend.c The node suspend capabilities APIs should not have been put into util.[ch]. Instead move them into virnodesuspend.[ch] * src/util/util.c, src/util/util.h: Remove suspend capabilities APIs * src/util/virnodesuspend.c, src/util/virnodesuspend.h: Add suspend capabilities APIs * src/qemu/qemu_capabilities.c: Include virnodesuspend.h
2011-11-29 14:42:58 +00:00
#include "virnodesuspend.h"
numatune: create new module for numatune There are many places with numatune-related code that should be put into special numatune_conf and this patch creates a basis for that. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-06-06 14:50:39 +00:00
#include "virnuma.h"
qemu: check the kvm host cpu max limits in virConnectGetDomainCapabilities The qemu limit and host limit both should be considered for the domain vcpu max limits. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
2016-06-24 15:04:13 +00:00
#include "virhostcpu.h"
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
#include "qemu_monitor.h"
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
#include "virstring.h"
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
#include "qemu_hostdev.h"
virQEMUCapsInitQMP: Don't dispose locked @vm When creating qemu capabilities, a dummy virDomainObj is created just because our monitor code expects that. However, the object is created locked already. Then, under cleanup label, we simply unref the object which results in whole domain object to be disposed. The object lock is destroyed subsequently, but hey - it's still locked: ==24845== Thread #14's call to pthread_mutex_destroy failed ==24845== with error code 16 (EBUSY: Device or resource busy) ==24845== at 0x4C3024E: pthread_mutex_destroy (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==24845== by 0x531F72E: virMutexDestroy (virthread.c:83) ==24845== by 0x5302977: virObjectLockableDispose (virobject.c:237) ==24845== by 0x5302A89: virObjectUnref (virobject.c:265) ==24845== by 0x1DD37866: virQEMUCapsInitQMP (qemu_capabilities.c:3397) ==24845== by 0x1DD37CC6: virQEMUCapsNewForBinary (qemu_capabilities.c:3481) ==24845== by 0x1DD381E2: virQEMUCapsCacheLookup (qemu_capabilities.c:3609) ==24845== by 0x1DD30F8A: virQEMUCapsInitGuest (qemu_capabilities.c:744) ==24845== by 0x1DD31889: virQEMUCapsInit (qemu_capabilities.c:1020) ==24845== by 0x1DD7DD36: virQEMUDriverCreateCapabilities (qemu_conf.c:888) ==24845== by 0x1DDC57C0: qemuStateInitialize (qemu_driver.c:803) ==24845== by 0x53DC743: virStateInitialize (libvirt.c:777) ==24845== Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-03-10 13:23:43 +00:00
#include "qemu_domain.h"
qemu: Fix typo in __QEMU_CAPSPRIV_H_ALLOW__
2017-03-22 15:22:15 +00:00
#define __QEMU_CAPSPRIV_H_ALLOW__
Implement infrastracture for mocking up QEMU capabilities cache The main purpose of this patch is to introduce test mode to virQEMUCapsCacheLookup(). This is done by adding a global variable, which effectively overrides binary name. This variable is supposed to be set by test suite. The second addition is qemuTestCapsCacheInsert() function which allows the test suite to actually populate the cache. Signed-off-by: Pavel Fedin <p.fedin@samsung.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2015-09-09 14:03:14 +00:00
#include "qemu_capspriv.h"
qemu: caps: Move QAPI schema related code into separate file Extract the code into qemu_qapi.c/h so that we separate it from various parts of the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-20 07:44:11 +00:00
#include "qemu_qapi.h"
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
Add support for QEMU -add-fd support detection Add support for QEMU -add-fd command line parameter detection. This intentionally rejects qemu 1.2, where 'add-fd' QMP did not allow full control of set ids, and where there was no command line counterpart, but accepts qemu 1.3. Signed-off-by: Eric Blake <eblake@redhat.com>
2013-01-29 16:52:17 +00:00
#include <fcntl.h>
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
#include <sys/stat.h>
#include <unistd.h>
#include <sys/wait.h>
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
#include <stdarg.h>
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
#include <sys/utsname.h>
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
#define VIR_FROM_THIS VIR_FROM_QEMU
Add virLogSource variables to all source files Any source file which calls the logging APIs now needs to have a VIR_LOG_INIT("source.name") declaration at the start of the file. This provides a static variable of the virLogSource type. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-02-28 12:16:17 +00:00
VIR_LOG_INIT("qemu.qemu_capabilities");
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
/* While not public, these strings must not change. They
* are used in domain status files which are read on
* daemon restarts
*/
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 0 */
"kqemu",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"vnc-colon",
"no-reboot",
"drive",
"drive-boot",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 5 */
"name",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"uuid",
"domid",
"vnet-hdr",
"migrate-kvm-stdio",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 10 */
"migrate-qemu-tcp",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"migrate-qemu-exec",
"drive-cache-v2",
"kvm",
"drive-format",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 15 */
"vga",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"0.10",
"pci-device",
"mem-path",
"drive-serial",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 20 */
"xen-domid",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"migrate-qemu-unix",
"chardev",
"enable-kvm",
"monitor-json",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 25 */
"balloon",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"device",
"sdl",
"smp-topology",
"netdev",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 30 */
"rtc",
qemu: fix typo in name - should be VHOST_NET, not VNET_HOST NB: the enum that uses the string vnet-host (now changed to vhost-net) is used in XML, but fortunately that hasn't been in an official release yet, so it can still be fixed.
2011-05-23 17:38:32 +00:00
"vhost-net",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"rtc-td-hack",
"no-hpet",
"no-kvm-pit",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 35 */
"tdf",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"pci-configfd",
"nodefconfig",
"boot-menu",
"enable-kqemu",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 40 */
"fsdev",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"nesting",
"name-process",
"drive-readonly",
"smbios-type",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 45 */
"vga-qxl",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"spice",
"vga-none",
"migrate-qemu-fd",
"boot-index",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 50 */
"hda-duplex",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"drive-aio",
"pci-multibus",
"pci-bootindex",
"ccid-emulated",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 55 */
"ccid-passthru",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
"chardev-spicevmc",
"device-spicevmc",
"virtio-tx-alg",
"device-qxl-vga",
check whether qemu supports multi function PCI device qemu supports multi function PCI device at least version 0.13.0.
2011-05-09 06:59:16 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 60 */
"pci-multifunction",
qemu: domain I/O asynchronous handling For virtio disks and interfaces, qemu allows users to enable or disable ioeventfd feature. This means, qemu can execute domain code, while another thread waits for I/O event. Basically, in some cases it is win, in some loss. This feature is available via 'ioeventfd' attribute in disk and interface <driver> element. It accepts 'on' and 'off'. Leaving this attribute out defaults to hypervisor decision.
2011-06-20 08:26:47 +00:00
"virtio-blk-pci.ioeventfd",
bios: Add support for SGA This patch creates new <bios> element which, at this time has only the attribute useserial='yes|no'. This attribute allow users to use Serial Graphics Adapter and see BIOS messages from the very first moment domain boots up. Therefore, users can choose boot medium, set PXE, etc.
2011-07-08 07:56:17 +00:00
"sga",
qemu: support event_idx parameter for virtio disk and net devices In some versions of qemu, both virtio-blk-pci and virtio-net-pci devices can have an event_idx setting that determines some details of event processing. When it is enabled, it "reduces the number of interrupts and exits for the guest". qemu will automatically enable this feature when it is available, but there may be cases where this new feature could actually make performance worse (NB: no such case has been found so far). As a safety switch in case such a situation is encountered in the field, this patch adds a new attribute "event_idx" to the <driver> element of both disk and interface devices. event_idx can be set to "on" (to force event_idx on in case qemu has it disabled by default) or "off" (for force event_idx off). In the case that event_idx support isn't present in qemu, the attribute is ignored (this on the advice of the qemu developer). docs/formatdomain.html.in: document the new flag (marking it as "don't mess with this!" docs/schemas/domain.rng: add event_idx in appropriate places src/conf/domain_conf.[ch]: add event_idx to parser and formatter src/libvirt_private.syms: export virDomainVirtioEventIdx(From|To)String src/qemu/qemu_capabilities.[ch]: detect and report event_idx in disk/net src/qemu/qemu_command.c: add event_idx parameter to qemu commandline when appropriate. tests/qemuxml2argvdata/qemuxml2argv-event_idx.args, tests/qemuxml2argvdata/qemuxml2argv-event_idx.xml, tests/qemuxml2argvtest.c, tests/qemuxml2xmltest.c: test cases for event_idx.
2011-08-13 06:32:45 +00:00
"virtio-blk-pci.event_idx",
"virtio-net-pci.event_idx",
Add various USB devices QEMU_CAPS
2011-09-02 12:56:50 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 65 */
"cache-directsync",
Add various USB devices QEMU_CAPS
2011-09-02 12:56:50 +00:00
"piix3-usb-uhci",
"piix4-usb-uhci",
"usb-ehci",
"ich9-usb-ehci1",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 70 */
"vt82c686b-usb-uhci",
Add various USB devices QEMU_CAPS
2011-09-02 12:56:50 +00:00
"pci-ohci",
"usb-redir",
Add USB hub device domain parsing and serialization code, qemu driver backend and a couple of test
2011-09-02 14:20:40 +00:00
"usb-hub",
qemu: Fix shutdown regression with buggy qemu The commit that prevents disk corruption on domain shutdown (96fc4784177ecb70357518fa863442455e45ad0e) causes regression with QEMU 0.14.* and 0.15.* because of a regression bug in QEMU that was fixed only recently in QEMU git. The affected versions of QEMU do not quit on SIGTERM if started with -no-shutdown, which we use to implement fake reboot. Since -no-shutdown tells QEMU not to quit automatically on guest shutdown, domains started using the affected QEMU cannot be shutdown properly and stay in a paused state. This patch disables fake reboot feature on such QEMU by not using -no-shutdown, which makes shutdown work as expected. However, virDomainReboot will not work in this case and it will report "Requested operation is not valid: Reboot is not supported with this QEMU binary".
2011-09-21 08:25:29 +00:00
"no-shutdown",
Add unsafe cache mode support for disk driver QEMU 0.13 introduced cache=unsafe for -drive, this patch exposes it in the libvirt layer. * Introduced a new QEMU capability flag ($prefix_CACHE_UNSAFE), as even if $prefix_CACHE_V2 is set, we can't know if unsafe is supported. * Improved the reliability of qemu cache type detection.
2011-09-22 19:33:47 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 75 */
"cache-unsafe",
qemu: add ability to set PCI device "rombar" on or off This patch was made in response to: https://bugzilla.redhat.com/show_bug.cgi?id=738095 In short, qemu's default for the rombar setting (which makes the firmware ROM of a PCI device visible/not on the guest) was previously 0 (not visible), but they recently changed the default to 1 (visible). Unfortunately, there are some PCI devices that fail in the guest when rombar is 1, so the setting must be exposed in libvirt to prevent a regression in behavior (it will still require explicitly setting <rom bar='off'/> in the guest XML). rombar is forced on/off by adding: <rom bar='on|off'/> inside a <hostdev> element that defines a PCI device. It is currently ignored for all other types of devices. At the moment there is no clean method to determine whether or not the rombar option is supported by QEMU - this patch uses the advice of a QEMU developer to assume support for qemu-0.12+. There is currently a patch in the works to put this information in the output of "qemu-kvm -device pci-assign,?", but of course if we switch to keying off that, we would lose support for setting rombar on all the versions of qemu between 0.12 and whatever version gets that patch.
2011-09-20 17:31:52 +00:00
"rombar",
Add AHCI support to qemu driver Tested with multiple AHCI controllers and multiple disks attached to a controller. E.g., <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/test/disk0.raw'/> <target dev='sda' bus='sata'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/test/disk1.raw'/> <target dev='sdb' bus='sata'/> <address type='drive' controller='0' bus='0' unit='1'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/var/lib/libvirt/images/test/disk2.raw'/> <target dev='sdc' bus='sata'/> <address type='drive' controller='1' bus='0' unit='0'/> </disk> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> <controller type='sata' index='1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </controller>
2011-09-28 03:46:08 +00:00
"ich9-ahci",
qemu: Add a capability flag for -no-acpi Currently non-x86 guests must have <acpi/> defined in <features> to prevent libvirt from running qemu with -no-acpi. Although it works, it is a hack. Instead add a capability flag which indicates whether qemu understands the -no-acpi option. Use it to control whether libvirt emits -no-acpi. Current versions of qemu always display -no-acpi in their help output, so this patch has no effect. However the development version of qemu has been modified such that -no-acpi is only displayed when it is actually supported. Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
2011-12-20 01:08:29 +00:00
"no-acpi",
qemu: Support readonly filesystem passthrough Upstream QEMU starts to support it from commit 2c74c2cb.
2011-12-21 15:51:29 +00:00
"fsdev-readonly",
qemu: add capabilities flags related to SG_IO This patch adds two capabilities flags to deal with various aspects of supporting SG_IO commands on virtio-blk-pci devices: QEMU_CAPS_VIRTIO_BLK_SCSI set if -device virtio-blk-pci accepts the scsi="on|off" option When present, this is on by default, but can be set to off to disable SG_IO functions. QEMU_CAPS_VIRTIO_BLK_SG_IO set if SG_IO commands are supported in the virtio-blk-pci driver (present since qemu 0.11 according to a qemu developer, if I understood correctly)
2011-11-29 18:37:27 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 80 */
"virtio-blk-pci.scsi",
qemu: add capabilities flags related to SG_IO This patch adds two capabilities flags to deal with various aspects of supporting SG_IO commands on virtio-blk-pci devices: QEMU_CAPS_VIRTIO_BLK_SCSI set if -device virtio-blk-pci accepts the scsi="on|off" option When present, this is on by default, but can be set to off to disable SG_IO functions. QEMU_CAPS_VIRTIO_BLK_SG_IO set if SG_IO commands are supported in the virtio-blk-pci driver (present since qemu 0.11 according to a qemu developer, if I understood correctly)
2011-11-29 18:37:27 +00:00
"blk-sg-io",
qemu: Support copy on read for disk The new introduced optional attribute "copy_on_read</code> controls whether to copy read backing file into the image file. The value can be either "on" or "off". Copy-on-read avoids accessing the same backing file sectors repeatedly and is useful when the backing file is over a slow network. By default copy-on-read is off.
2012-01-12 09:31:14 +00:00
"drive-copy-on-read",
qemu: Add support for host CPU modes This adds support for host-model and host-passthrough CPU modes to qemu driver. The host-passthrough mode is mapped to -cpu host.
2011-12-21 12:47:17 +00:00
"cpu-host",
Add new attribute wrpolicy to <driver> element This introduces new attribute wrpolicy with only supported value as immediate. This will be an optional attribute with no defaults. This helps specify whether to skip the host page cache. When wrpolicy is specified, meaning when wrpolicy=immediate a writeback is explicitly initiated for the dirty pages in the host page cache as part of the guest file write operation. Usage: <filesystem type='mount' accessmode='passthrough'> <driver type='path' wrpolicy='immediate'/> <source dir='/export/to/guest'/> <target dir='mount_tag'/> </filesystem> Currently this only works with type='mount' for the QEMU/KVM driver. Signed-off-by: Deepak C Shetty <deepakcs@linux.vnet.ibm.com>
2012-01-17 12:44:18 +00:00
"fsdev-writeout",
Added capability checking for block <iotune> setting. There was missing capability for blkiotune and thus specifying these settings caused libvirt to run qemu with invalid parameters and then reporting qemu error instead of the standard libvirt one. The support for blkiotune setting was added in upstream qemu repo under commit 0563e191516289c9d2f282a8c50f2eecef2fa773.
2012-01-18 16:42:33 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 85 */
"drive-iotune",
qemu: Set capabilities based on supported monitor commands In the future (my next patch in fact) we may want to make decisions depending on qemu having a monitor command or not. Therefore, we want to set qemuCaps flag instead of querying on the monitor each time we are about to make that decision.
2012-02-13 11:19:24 +00:00
"system_wakeup",
qemu: New cap flag to indicate if channel is supported by scsi-disk
2012-02-27 10:20:21 +00:00
"scsi-disk.channel",
qemu: Use scsi-block for lun passthrough instead of scsi-disk And don't allow to hotplug a usb disk with "device == lun". This is the missed pieces in previous virtio-scsi patchset: http://www.redhat.com/archives/libvir-list/2012-February/msg01052.html
2012-03-12 14:19:56 +00:00
"scsi-block",
snapshot: add qemu capability for 'transaction' command We need a capability bit to gracefully error out if some of the additions in future patches can't be implemented by the running qemu. * src/qemu/qemu_capabilities.h (QEMU_CAPS_TRANSACTION): New cap. * src/qemu/qemu_capabilities.c (qemuCaps): Name it. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONCheckCommands): Set it.
2012-03-14 22:29:21 +00:00
"transaction",
blockjob: add qemu capabilities related to block pull jobs RHEL 6.2 was released with an early version of block jobs, which only worked on the qed file format, where the commands were spelled with underscore (contrary to QMP style), and where 'block_job_cancel' was synchronous and did not trigger an event. The upcoming qemu 1.1 release has fixed these short-comings [1][2]: the commands now work on multiple file types, are spelled with dash, and 'block-job-cancel' is asynchronous and emits an event upon conclusion. [1]qemu commit 370521a1d6f5537ea7271c119f3fbb7b0fa57063 [2]https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01248.html This patch recognizes the new spellings, and fixes virDomainBlockRebase to give a graceful error when talking to a too-old qemu on a partial rebase attempt. Fixes for the new semantics will come later. This patch also removes a bogus ATTRIBUTE_NONNULL mistakenly added in commit 10ec36e2. * src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCKJOB_SYNC) (QEMU_CAPS_BLOCKJOB_ASYNC): New bits. * src/qemu/qemu_capabilities.c (qemuCaps): Name them. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONCheckCommands): Set them. (qemuMonitorJSONBlockJob): Manage both command names. (qemuMonitorJSONDiskSnapshot): Minor formatting fix. * src/qemu/qemu_monitor.h (qemuMonitorBlockJob): Alter signature. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockJob): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorBlockJob): Pass through capability bit. * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Update callers.
2012-04-11 21:40:16 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 90 */
"block-job-sync",
blockjob: add qemu capabilities related to block pull jobs RHEL 6.2 was released with an early version of block jobs, which only worked on the qed file format, where the commands were spelled with underscore (contrary to QMP style), and where 'block_job_cancel' was synchronous and did not trigger an event. The upcoming qemu 1.1 release has fixed these short-comings [1][2]: the commands now work on multiple file types, are spelled with dash, and 'block-job-cancel' is asynchronous and emits an event upon conclusion. [1]qemu commit 370521a1d6f5537ea7271c119f3fbb7b0fa57063 [2]https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01248.html This patch recognizes the new spellings, and fixes virDomainBlockRebase to give a graceful error when talking to a too-old qemu on a partial rebase attempt. Fixes for the new semantics will come later. This patch also removes a bogus ATTRIBUTE_NONNULL mistakenly added in commit 10ec36e2. * src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCKJOB_SYNC) (QEMU_CAPS_BLOCKJOB_ASYNC): New bits. * src/qemu/qemu_capabilities.c (qemuCaps): Name them. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONCheckCommands): Set them. (qemuMonitorJSONBlockJob): Manage both command names. (qemuMonitorJSONDiskSnapshot): Minor formatting fix. * src/qemu/qemu_monitor.h (qemuMonitorBlockJob): Alter signature. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockJob): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorBlockJob): Pass through capability bit. * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Update callers.
2012-04-11 21:40:16 +00:00
"block-job-async",
qemu: Split scsi-disk into into scsi-hd and scsi-cd A "scsi-disk" device can be either a hard disk or a CD-ROM, if there is ",media=cdrom" specified for the backend, it's a CD-ROM, otherwise it's a hard disk. But upstream qemu splitted "scsi-disk" into "scsi-hd" and "scsi-cd" since commit b443ae, and ",media=cdrom" is not required for scsi-cd anymore. "scsi-disk" is still supported for backwards compatibility, but no doubt we should go foward.
2012-04-17 09:08:05 +00:00
"scsi-cd",
qemu: Split ide-drive into ide-cd and ide-hd A "ide-drive" device can be either a hard disk or a CD-ROM, if there is ",media=cdrom" specified for the backend, it's a CD-ROM, otherwise it's a hard disk. Upstream qemu splitted "ide-drive" into "ide-hd" and "ide-cd" since commit 1f56e32, and ",media=cdrom" is not required for ide-cd anymore. "ide-drive" is still supported for backwards compatibility, but no doubt we should go foward.
2012-04-17 09:16:52 +00:00
"ide-cd",
qemu: Add support for -no-user-config Thanks to this new option we are now able to use modern CPU models (such as Westmere) defined in external configuration file. The qemu-1.1{,-device} data files for qemuhelptest are filled in with qemu-1.1-rc2 output for now. I will update those files with real qemu-1.1 output once it is released.
2012-04-26 10:11:49 +00:00
"no-user-config",
qemu: test CAPS_HDA_MICRO
2012-05-15 22:55:08 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 95 */
"hda-micro",
qemu: allow the client to choose the vmcore's format This patch updates qemu driver to allow the client to choose the vmcore's format: memory only or including device state.
2012-06-12 03:06:33 +00:00
"dump-guest-memory",
qemu: Add xhci support qemu 1.1 features a xhci controller, this patch adds support for it. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2012-06-21 13:45:25 +00:00
"nec-usb-xhci",
S390: Add support for virtio-s390 devices. The s390(x) architecture doesn't feature a PCI bus. For the purpose of supporting virtio devices a virtual bus called virtio-s390 is used. A new address type VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_S390 is used to distinguish the virtio devices on s390 from PCI-based virtio devices. V3 Change: updated QEMU_CAPS_VIRTIO_S390 to fit upstream. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2012-06-29 15:02:05 +00:00
"virtio-s390",
Wire up handling for QMP's BALLOON_EVENT If QEMU supports the BALLOON_EVENT QMP event, then we can avoid invoking 'query-balloon' when returning XML or the domain info. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add QEMU_CAPS_BALLOON_EVENT * src/qemu/qemu_driver.c: Skip query-balloon in qemudDomainGetInfo and qemuDomainGetXMLDesc if we have QEMU_CAPS_BALLOON_EVENT set * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h: Check for BALLOON_EVENT at connect to monitor. Add callback for balloon change notifications * src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h: Add handling of BALLOON_EVENT and impl 'query-events' check Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-07-12 15:45:57 +00:00
"balloon-event",
qemu: test CAPS_HDA_MICRO
2012-05-15 22:55:08 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 100 */
"bridge",
qemu: add capabilities flags related to scsi controller QEMU_CAPS_SCSI_LSI set the flag when "lsi53c895a", bus PCI, alias "lsi" in the output of "qemu -device ?" -device lsi in qemu command line QEMU_CAPS_VIRTIO_SCSI_PCI set the flag when "name "virtio-scsi-pci", bus PCI" in the output of qemu devices query. -device virtio-scsi-pci in qemu command line
2012-08-08 06:25:24 +00:00
"lsi",
"virtio-scsi-pci",
Rename iolimit to blockio. After discussion with DB we decided to rename the new iolimit element as it creates the impression it would be there to limit (i.e. throttle) I/O instead of specifying immutable characteristics of a block device. This is also backed by the fact that the term I/O Limits has vanished from newer storage admin documentation. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2012-09-04 14:30:55 +00:00
"blockio",
qemu: Add support for S3/S4 state configuration This patch adds support for running qemu guests with the required parameters to forcefully enable or disable BIOS advertising of S3 and S4 states. The support for this is added to capabilities and there is also a qemu command parameter parsing implemented.
2012-08-02 10:14:39 +00:00
"disable-s3",
Add -netdev bridge capabilities This patch adds the capability in libvirt to check if -netdev bridge option is supported or not. Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com> Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com>
2012-08-03 20:33:05 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 105 */
"disable-s4",
qemu: add usb-redir.filter qemu capability flag Add a qemu flag for USB redirection filter support. The output: usb-redir.chardev=chr usb-redir.debug=uint8 usb-redir.filter=string usb-redir.port=string
2012-08-19 15:42:44 +00:00
"usb-redir.filter",
qemu: Add caps to indentify if setting wwn is supported by qemu This assumes ide-drive.wwn, ide-hd.wwn, ide-cd.wwn were supported at the same time, similar for scsi-disk.wwn, scsi-hd.wwn, and scsi-cd.wwn. So only two new caps (QEMU_CAPS_IDE_DRIVE_WWN, and QEMU_CAPS_SCSI_DISK_WWN) are introduced.
2012-09-18 02:12:11 +00:00
"ide-drive.wwn",
"scsi-disk.wwn",
qemu: add capability flag for seccomp sandbox This series adds support to run QEMU with seccomp sandbox enabled. It can be configured in qemu.conf to on, off, or the QEMU default, which is off in 1.2. Default value is the QEMU default.
2012-09-18 07:24:51 +00:00
"seccomp-sandbox",
qemu: Add support for reboot-timeout This patch adds support for "-boot reboot-timeout=rb_time" that is added in QEMU.
2012-09-18 10:31:30 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 110 */
"reboot-timeout",
qemu: add support for dump-guest-core option The "dump-guest-core' option is new option for the machine type (-machine pc,dump-guest-core) that controls whether the guest memory will be marked as dumpable. While testing this, I've found out that the value for the '-M' options is not parsed correctly when additional parameters are used. However, when '-machine' is used for the same options, it gets parsed as expected. That's why this patch also modifies the parsing and creating of the command line, so both '-M' and '-machine' are recognized. In QEMU's help there is only mention of the 'machine parameter now with no sign of the older '-M'.
2012-08-15 07:59:24 +00:00
"dump-guest-core",
qemu: wait for SPICE to migrate Recently, there have been some improvements made to qemu so it supports seamless migration or something very close to it. However, it requires libvirt interaction. Once qemu is migrated, the SPICE server needs to send its internal state to the destination. Once it's done, it fires SPICE_MIGRATE_COMPLETED event and this fact is advertised in 'query-spice' output as well. We must not kill qemu until SPICE server finishes the transfer.
2012-09-20 09:15:31 +00:00
"seamless-migration",
blockjob: manage qemu block-commit monitor command qemu 1.3 will be adding a 'block-commit' monitor command, per qemu.git commit ed61fc1. It matches nicely to the libvirt API virDomainBlockCommit. * src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCK_COMMIT): New bit. * src/qemu/qemu_capabilities.c (qemuCapsProbeQMPCommands): Set it. * src/qemu/qemu_monitor.h (qemuMonitorBlockCommit): New prototype. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockCommit): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorBlockCommit): Implement it. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockCommit): Likewise. (qemuMonitorJSONHandleBlockJobImpl) (qemuMonitorJSONGetBlockJobInfoOne): Handle new event type.
2012-10-03 21:13:21 +00:00
"block-commit",
qemu: Don't blindly assume VNC is supported Currently it's assumed that qemu always supports VNC, however it is definitely possible to compile qemu without VNC support so we should at the very least check for it and handle that correctly.
2012-10-19 19:40:52 +00:00
"vnc",
blockjob: add qemu capabilities related to block jobs Upstream qemu 1.3 is adding two new monitor commands, 'drive-mirror' and 'block-job-complete'[1], which can drive live block copy and storage migration. [Additionally, RHEL 6.3 had backported an earlier version of most of the same functionality, but under the names '__com.redhat_drive-mirror' and '__com.redhat_drive-reopen' and with slightly different JSON arguments, and has been using patches similar to these upstream patches for several months now.] The libvirt API virDomainBlockRebase as already committed for 0.9.12 is flexible enough to expose the basics of block copy, but some additional features in the 'drive-mirror' qemu command, such as setting error policy, setting granularity, or using a persistent bitmap, may later require a new libvirt API virDomainBlockCopy. I will wait to add that API until we know more about what qemu 1.3 will finally provide. This patch caters only to the upstream qemu 1.3 interface, although I have proven that the changes for RHEL 6.3 can be isolated to just qemu_monitor_json.c, and the rest of this series will gracefully handle either interface once the JSON differences are papered over in a downstream patch. For consistency with other block job commands, libvirt must handle the bandwidth argument as MiB/sec from the user, even though qemu exposes the speed argument as bytes/sec; then again, qemu rounds up to cluster size internally, so using MiB hides the worst effects of that rounding if you pass small numbers. [1]https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg04123.html * src/qemu/qemu_capabilities.h (QEMU_CAPS_DRIVE_MIRROR) (QEMU_CAPS_DRIVE_REOPEN): New bits. * src/qemu/qemu_capabilities.c (qemuCaps): Name them. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONCheckCommands): Set them. (qemuMonitorJSONDriveMirror, qemuMonitorDrivePivot): New functions. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONDriveMirror) (qemuMonitorDrivePivot): Declare them. * src/qemu/qemu_monitor.c (qemuMonitorDriveMirror) (qemuMonitorDrivePivot): New passthroughs. * src/qemu/qemu_monitor.h (qemuMonitorDriveMirror) (qemuMonitorDrivePivot): Declare them.
2012-09-28 23:29:53 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 115 */
"drive-mirror",
qemu: add bootindex for usb-host and usb-redir devices Allow bootindex to be specified for redirected USB devices and host USB devices. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=805414
2012-11-14 14:51:30 +00:00
"usb-redir.bootindex",
"usb-host.bootindex",
qemu: nicer error message if live disk snapshot unsupported Without this patch, attempts to create a disk snapshot when qemu is too old results in a cryptic message: virsh # snapshot-create 23 --disk-only error: operation failed: Failed to take snapshot: unknown command: 'snapshot_blkdev' Now it reports: virsh # snapshot-create 23 --disk-only error: unsupported configuration: live disk snapshot not supported with this QEMU binary All versions of qemu that support live disk snapshot also support QMP (basically upstream qemu 1.1 and later, and backports to RHEL 6.2). * src/qemu/qemu_capabilities.h (QEMU_CAPS_DISK_SNAPSHOT): New capability. * src/qemu/qemu_capabilities.c (qemuCaps): Track it. (qemuCapsProbeQMPCommands): Set it. * src/qemu/qemu_driver.c (qemuDomainSnapshotCreateDiskActive): Use it. * src/qemu/qemu_monitor.c (qemuMonitorDiskSnapshot): Simplify. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONDiskSnapshot): Likewise. * src/qemu/qemu_monitor_text.h (qemuMonitorTextDiskSnapshot): Delete. * src/qemu/qemu_monitor_text.c (qemuMonitorTextDiskSnapshot): Likewise.
2012-12-03 21:25:30 +00:00
"blockdev-snapshot-sync",
qemu: add qemu vga devices caps and one cap to mark them usable QEMU_CAPS_DEVICE_QXL -device qxl QEMU_CAPS_DEVICE_VGA -device VGA QEMU_CAPS_DEVICE_CIRRUS_VGA -device cirrus-vga QEMU_CAPS_DEVICE_VMWARE_SVGA -device vmware-svga QEMU_CAPS_DEVICE_VIDEO_PRIMARY /* safe to use -device XXX for primary video device */ Fix a typo in qemuCapsObjectTypes, the string 'qxl' here should be -device qxl rather than -vga [...|qxl|..]
2012-12-14 07:06:31 +00:00
"qxl",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 120 */
"VGA",
qemu: add qemu vga devices caps and one cap to mark them usable QEMU_CAPS_DEVICE_QXL -device qxl QEMU_CAPS_DEVICE_VGA -device VGA QEMU_CAPS_DEVICE_CIRRUS_VGA -device cirrus-vga QEMU_CAPS_DEVICE_VMWARE_SVGA -device vmware-svga QEMU_CAPS_DEVICE_VIDEO_PRIMARY /* safe to use -device XXX for primary video device */ Fix a typo in qemuCapsObjectTypes, the string 'qxl' here should be -device qxl rather than -vga [...|qxl|..]
2012-12-14 07:06:31 +00:00
"cirrus-vga",
"vmware-svga",
"device-video-primary",
S390: Enable SCLP Console in QEMU driver This is the QEMU backend code for the SCLP console support. It includes SCLP capability detection, QEMU command line generation and a test case. Signed-off-by: J.B. Joret <jb@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-01-07 17:17:15 +00:00
"s390-sclp",
qemu: Fix grouping of capabilities strings Commit f8d478b6dfc46a0ad2459844b96937599dec06e1 broke the grouping by five items.
2013-01-11 16:43:49 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 125 */
"usb-serial",
qemu: add usb-net caps flag QEMU_CAPS_DEVICE_USB_NET /* -device usb-net */
2013-01-03 07:13:05 +00:00
"usb-net",
Add support for QEMU -add-fd support detection Add support for QEMU -add-fd command line parameter detection. This intentionally rejects qemu 1.2, where 'add-fd' QMP did not allow full control of set ids, and where there was no command line counterpart, but accepts qemu 1.3. Signed-off-by: Eric Blake <eblake@redhat.com>
2013-01-29 16:52:17 +00:00
"add-fd",
qemu: Introduce NBD_SERVER capability This just keeps track whether qemu knows nbd-server-* commands so we can use it during migration or not.
2012-11-21 13:28:44 +00:00
"nbd-server",
qemu: Implement support for default 'random' backend for virtio-rng This patch implements support for the virtio-rng-pci device and the rng-random backend in qemu. Two capabilities bits are added to track support for those: QEMU_CAPS_DEVICE_VIRTIO_RNG - for the device support and QEMU_CAPS_OBJECT_RNG_RANDOM - for the backend support. qemu is invoked with these additional parameters if the device is enabled: -object rng-random,id=rng0,filename=/test/phile (to add the backend) -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (to add the device)
2013-01-11 16:48:21 +00:00
"virtio-rng",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 130 */
"rng-random",
qemu: Implement support for EGD backend for virtio-rng This patch adds a new capability bit QEMU_CAPS_OBJECT_RNG_EGD and code to support the egd backend for the VirtIO RNG device. The device is added by 3 qemu command line options: -chardev socket,id=charrng0,host=1.2.3.4,port=1234 (communication backend) -object rng-egd,chardev=charrng0,id=rng0 (RNG protocol client) -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (the RNG device)
2013-02-13 10:22:23 +00:00
"rng-egd",
qemu: add dtb option support The "dtb" option sets the filename for the device tree. If without this option support, "-dtb file" will be converted into <qemu:commandline> in domain XML file. For example, '-dtb /media/ram/test.dtb' will be converted into <qemu:commandline> <qemu:arg value='-dtb'/> <qemu:arg value='/media/ram/test.dtb'/> </qemu:commandline> This is not very friendly. This patchset add special <dtb> tag like <kernel> and <initrd> which is easier for user to write domain XML file. <os> <type arch='ppc' machine='ppce500v2'>hvm</type> <kernel>/media/ram/uImage</kernel> <initrd>/media/ram/ramdisk</initrd> <dtb>/media/ram/test.dtb</dtb> <cmdline>root=/dev/ram rw console=ttyS0,115200</cmdline> </os> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-03-14 04:49:43 +00:00
"virtio-ccw",
"dtb",
qemu: add support for LSI MegaRAID SAS1078 (aka megasas) SCSI controller This does nothing more than adding the new device and capability. The device is present since QEMU 1.2.0. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-03-21 14:11:39 +00:00
"megasas",
qemu: Allow migration over IPv6 Allow migration over IPv6 by listening on [::] instead of 0.0.0.0 when QEMU supports it (QEMU_CAPS_IPV6_MIGRATION) and there is at least one v6 address configured on the system. Use virURIParse in qemuMigrationPrepareDirect to allow parsing IPv6 addresses, which would cause an 'incorrect :port' error message before. Move setting of migrateFrom from qemuMigrationPrepare{Direct,Tunnel} after domain XML parsing, since we need the QEMU binary path from it to get its capabilities. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=846013
2013-03-22 13:52:25 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 135 */
"ipv6-migration",
Optimize machine option to set more options with it Currently, -machine option is used only when dump-guest-core is set. To use options defined in machine option for newer version of QEMU, it needs to use -machine xxx, and to be compatible with older version -M, this patch adds QEMU_CAPS_MACHINE_OPT capability for newer version which supports -machine option. Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-03-29 05:22:46 +00:00
"machine-opt",
Add USB option capability To avoid the collision for creating USB controllers in machine->init() and -device xx command line, it needs to set usb=off to avoid one USB controller created in machine->init(). So that libvirt can use -device or -usb to create USB controller sucessfully. So QEMU_CAPS_MACHINE_USB_OPT capability is added, and it is for QEMU v1.3.0 onwards which supports USB option. Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com>
2013-04-07 08:31:57 +00:00
"machine-usb-opt",
Add QMP probing for TPM Probe for QEMU's QMP TPM support by querying the lists of supported TPM models (query-tpm-models) and backend types (query-tpm-types). The setting of the capability flags following the strings returned from the commands above is only provided in the patch where domain_conf.c gets TPM support due to dependencies on functions only introduced there. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
"tpm-passthrough",
"tpm-tis",
qemu: Add command line builder and parser for NVRAM. This patch is to add command line builder and parser for NVRAM device, and add test cases. Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com>
2013-04-25 08:46:04 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 140 */
"nvram",
qemu: New cap flags for scsi-generic Adding two cap flags for scsi-generic: QEMU_CAPS_SCSI_GENERIC QEMU_CAPS_SCSI_GENERIC_BOOTINDEX Signed-off-by: Han Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: Osier Yang <jyang@redhat.com>
2013-05-03 18:07:21 +00:00
"pci-bridge",
"vfio-pci",
"vfio-pci.bootindex",
"scsi-generic",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 145 */
"scsi-generic.bootindex",
qemu: detect -machine mem-merge capability * src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d813; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
2013-05-14 05:25:49 +00:00
"mem-merge",
qemu: Add VNC WebSocket support Adding a VNC WebSocket support for QEMU driver. This functionality is in upstream qemu from commit described as v1.3.0-982-g7536ee4, so the capability is being recognized based on QEMU version for now.
2013-04-30 14:26:43 +00:00
"vnc-websocket",
qemu: Support discard for disk QEMU introduced "discard" option for drive since commit a9384aff53, <...> @var{discard} is one of "ignore" (or "off") or "unmap" (or "on") and controls whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap}) requests are ignored or passed to the filesystem. Some machine types may not support discard requests. </...> This patch exposes the support in libvirt. QEMU supported "discard" for "-drive" since v1.5.0-rc0: % git tag --contains a9384aff53 contains v1.5.0-rc0 v1.5.0-rc1 So this only detects the capability bit using virQEMUCapsProbeQMPCommandLine.
2013-05-14 12:44:54 +00:00
"drive-discard",
qemu: Implement support for locking domain's memory pages
2013-05-16 20:01:05 +00:00
"mlock",
qemu: new vnc display sharing policy caps flag QEMU_CAPS_VNC_SHARE_POLICY (qemu >= 1.1)
2013-05-21 14:31:47 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 150 */
"vnc-share-policy",
qemu: Add support for DEVICE_DELETED event
2013-07-11 15:07:26 +00:00
"device-del-event",
qemu: add dmi-to-pci-bridge controller This PCI controller, named "dmi-to-pci-bridge" in the libvirt config, and implemented with qemu's "i82801b11-bridge" device, connects to a PCI Express slot (e.g. one of the slots provided by the pcie-root controller, aka "pcie.0" on the qemu commandline), and provides 31 *non-hot-pluggable* PCI (*not* PCIe) slots, numbered 1-31. Any time a machine is defined which has a pcie-root controller (i.e. any q35-based machinetype), libvirt will automatically add a dmi-to-pci-bridge controller if one doesn't exist, and also add a pci-bridge controller. The reasoning here is that any useful domain will have either an immediate (startup time) or eventual (subsequent hot-plug) need for a standard PCI slot; since the pcie-root controller only provides PCIe slots, we need to connect a dmi-to-pci-bridge controller to it in order to get a non-hot-plug PCI slot that we can then use to connect a pci-bridge - the slots provided by the pci-bridge will be both standard PCI and hot-pluggable. Since pci-bridge devices themselves can not be hot-plugged into a running system (although you can hot-plug other devices into a pci-bridge's slots), any new pci-bridge controller that is added can (and will) be plugged into the dmi-to-pci-bridge as long as it has empty slots available. This patch is also changing the qemuxml2xml-pcie test from a "DO_TEST" to a "DO_DIFFERENT_TEST". This is so that the "before" xml can omit the automatically added dmi-to-pci-bridge and pci-bridge devices, and the "after" xml can include it - this way we are testing if libvirt is properly adding these devices.
2013-07-31 01:37:32 +00:00
"dmi-to-pci-bridge",
Build QEMU command line for pcihole64 QEMU commit 3984890 introduced the "pci-hole64-size" property, to i440FX-pcihost and q35-pcihost with a default setting of 2 GB. Translate <pcihole64>x<pcihole64/> to: -global q35-pcihost.pci-hole64-size=x for q35 machines and -global i440FX-pcihost.pci-hole64-size=x for i440FX-based machines. Error out on other machine types or if the size was specified but the pcihost device lacks 'pci-hole64-size' property. https://bugzilla.redhat.com/show_bug.cgi?id=990418
2013-08-12 11:48:34 +00:00
"i440fx-pci-hole64-size",
"q35-pci-hole64-size",
qemu: Add capability flag for usb-storage Allow use of the usb-storage device only if the new capability flag QEMU_CAPS_DEVICE_USB_STORAGE is set, which it is for qemu(-kvm) versions >= 0.12.1.2-rhel62-beta. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2013-08-23 10:38:10 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 155 */
"usb-storage",
qemu: Support setting the 'removable' flag for USB disks Add an attribute named 'removable' to the 'target' element of disks, which controls the removable flag. For instance, on a Linux guest it controls the value of /sys/block/$dev/removable. This option is only valid for USB disks (i.e. bus='usb'), and its default value is 'off', which is the same behaviour as before. To achieve this, 'removable=on' (or 'off') is appended to the '-device usb-storage' parameter sent to qemu when adding a USB disk via '-disk'. A capability flag QEMU_CAPS_USB_STORAGE_REMOVABLE was added to keep track if this option is supported by the qemu version used. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=922495 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2013-08-23 10:38:11 +00:00
"usb-storage.removable",
qemu: Support virtio-mmio transport for virtio on ARM Starting with qemu 1.6, the qemu-system-arm vexpress-a9 model has a hardcoded virtio-mmio transport which enables attaching all virtio devices. On the command line, we have to use virtio-XXX-device rather than virtio-XXX-pci, thankfully s390 already set the precedent here so it's fairly straight forward. At the XML level, this adds a new device address type virtio-mmio. The controller and addressing don't have any subelements at the moment because we they aren't needed for this usecase, but could be added later if needed. Add a test case for an ARM guest with one of every virtio device enabled.
2013-08-01 01:40:35 +00:00
"virtio-mmio",
qemu: support ich9-intel-hda audio device This resolves one of the issues in: https://bugzilla.redhat.com/show_bug.cgi?id=1003983 This device is identical to qemu's "intel-hda" device (known as "ich6" in libvirt), but has a different PCI device ID (which matches the ID of the hda audio built into the ich9 chipset, of course). It's not supported in earlier versions of qemu, so it requires a capability bit.
2013-09-24 14:17:38 +00:00
"ich9-intel-hda",
qemu: don't use deprecated -no-kvm-pit-reinjection Since qemu-kvm 1.1 [1] (since 1.3. in upstream QEMU [2]) '-no-kvm-pit-reinjection' has been deprecated. Use -global kvm-pit.lost_tick_policy=discard instead. https://bugzilla.redhat.com/show_bug.cgi?id=978719 [1] http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39 [2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f
2013-07-01 16:28:50 +00:00
"kvm-pit-lost-tick-policy",
qemu: add "-boot strict" to commandline whenever possible This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=888635 (which was already closed as CANTFIX because the qemu "-boot strict" commandline option wasn't available at the time). Problem: you couldn't have a domain that used PXE to boot, but also had an un-bootable disk device *even if that disk wasn't listed in the boot order*, because if PXE timed out (e.g. due to the bridge forwarding delay), the BIOS would move on to the next target, which would be the unbootable disk device (again - even though it wasn't given a boot order), and get stuck at a "BOOT DISK FAILURE, PRESS ANY KEY" message until a user intervened. The solution available since sometime around QEMU 1.5, is to add "-boot strict=on" to *every* qemu command. When this is done, if any devices have a boot order specified, then QEMU will *only* attempt to boot from those devices that have an explicit boot order, ignoring the rest.
2013-12-02 12:07:12 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 160 */
"boot-strict",
qemu: ask for -enable-fips when FIPS is required On a system that is enforcing FIPS, most libraries honor the current mode by default. Qemu, on the other hand, refused to honor FIPS mode unless you add the '-enable-fips' command line option; worse, this option is not discoverable via QMP, and is only present on binaries built for Linux. So, if we detect FIPS mode, then we unconditionally ask for FIPS; either qemu is new enough to have the option and then correctly cripple insecure VNC passwords, or it is so old that we are correctly avoiding a FIPS violation by preventing qemu from starting. Meanwhile, if we don't detect FIPS mode, then omitting the argument is safe whether the qemu has the option (but it would do nothing because FIPS is disabled) or whether qemu lacks the option (including in the case where we are not running on Linux). The testsuite was a bit interesting: we don't want our test to depend on whether it is being run in FIPS mode, so I had to tweak things to set the capability bit outside of our normal interaction with capability parsing. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035474 * src/qemu/qemu_capabilities.h (QEMU_CAPS_ENABLE_FIPS): New bit. * src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Conditionally set capability according to detection of FIPS mode. * src/qemu/qemu_command.c (qemuBuildCommandLine): Use it. * tests/qemucapabilitiestest.c (testQemuCaps): Conditionally set capability to test expected output. * tests/qemucapabilitiesdata/caps_1.2.2-1.caps: Update list. * tests/qemucapabilitiesdata/caps_1.6.0-1.caps: Likewise. Signed-off-by: Eric Blake <eblake@redhat.com>
2013-12-05 21:47:09 +00:00
"pvpanic",
"enable-fips",
qemu: introduce spiceport chardev backend Add a new backend for any character device. This backend uses channel in spice connection. This channel is similar to spicevmc, but all-purpose in contrast to spicevmc. Apart from spicevmc, spiceport-backed chardev will not be formatted into the command-line if there is no spice to use (with test for that as well). For this I moved the def->graphics counting to the start of the function so its results can be used in rest of the code even in the future. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-01-30 11:19:12 +00:00
"spice-file-xfer-disable",
"spiceport",
qemu: Add USB keyboard capability Add USB keyboard capability probing and test cases. Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2014-02-17 10:17:55 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 165 */
"usb-kbd",
qemu: add host-pci-multidomain capability Quite a long time ago, (apparently between qemu 0.12 and 0.13) qemu quietly began supporting the optional specification of a domain in the host-side address of all pci passthrough commands (by simply prepending it to the bus:slot.function format, as "dddd:bb:ss.f"). Since machines with multiple PCI domains are very rare, this never came up in practice, so libvirt was never updated to support it. This patch takes the first step to supporting specification of a non-0 domain in the host-side address of PCI devices being assigned to a domain, by adding a capability bit to indicate support "QEMU_CAPS_HOST_PCI_MULTIDOMAIN", and detect it. Since this support was added in a version prior to the minimum version required for QMP-style capabilities detection, the capability is always enabled for any qemu that uses QMP for capabilities detection. For older qemus, the only clue that a domain can be specified in the host pci address is the presence of the string "[seg:]" in the help string for -pcidevice. (Ironically, libvirt will not be modified to support specification of domain for -pcidevice, since any qemu new enough for us to care about also supports "-device pci-assign" or "-device vfio-pci", which are greatly preferred).
2014-04-29 15:11:45 +00:00
"host-pci-multidomain",
Add support for timestamping QEMU logs QEMU commit 5e2ac51 added a boolean '-msg timestamp=[on|off]' option, which can enable timestamps on errors: $ qemu-system-x86_64 -msg timestamp=on zghhdorf 2014-04-09T13:25:46.779484Z qemu-system-x86_64: -msg timestamp=on: could not open disk image zghhdorf: Could not open 'zghhdorf': No such file or directory Enable this timestamp if the QEMU binary supports it. Add a 'log_timestamp' option to qemu.conf for disabling this behavior.
2014-04-09 13:23:45 +00:00
"msg-timestamp",
blockjob: turn on qemu capability bit for active commit Use the probing functionality added in the last patch to turn on a capability bit when active commit is present, and gate active commit on that capability. For my own reference: the difference between BLOCKJOB_SYNC and BLOCKJOB_ASYNC is whether qemu generated an event at the conclusion of blockpull; basically, RHEL 6.2 was the only release of qemu that has the sync semantics and lacks the event. RHEL 6.3 added blockcopy, but also picked up on the upstream style of qemu generating events. As no one is likely to backport active commit to RHEL 6.2, it's safe for blockcommit to always require async blockjob support. Modifying qemucapabilitiestest is painful; the .replies files would be so much easier if they had comments correlating which command generated the given reply. Maybe I'll fix that up later... * src/qemu/qemu_capabilities.h (QEMU_CAPS_ACTIVE_COMMIT): New capability. * src/qemu/qemu_driver.c (qemuDomainBlockCommit): Use the new bit * src/qemu/qemu_capabilities.c (virQEMUCaps): Name the new bit. (virQEMUCapsProbeQMPCommands): Set it. * tests/qemucapabilitiesdata/caps_1.3.1-1.replies: Update. * tests/qemucapabilitiesdata/caps_1.4.2-1.replies: Likewise. * tests/qemucapabilitiesdata/caps_1.5.3-1.replies: Likewise. * tests/qemucapabilitiesdata/caps_1.6.0-1.replies: Likewise. * tests/qemucapabilitiesdata/caps_1.6.50-1.replies: Likewise. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-17 03:42:49 +00:00
"active-commit",
qemu: caps: Add capability for change-backing-file command This command allows to change the backing file name recorded in the metadata of a qcow (or other) image. The capability also notifies that the "block-stream" and "block-commit" commands understand the "backing-file" attribute.
2014-05-26 12:09:22 +00:00
"change-backing-file",
qemu: memory-backend-ram capability probing The numa patch series in qemu adds "memory-backend-ram" object type by which we can tell whether we can use such objects. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-05-07 15:20:15 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 170 */
"memory-backend-ram",
qemu: newer -numa parameter capability probing When qemu switched to using OptsVisitor for -numa parameter, it did two things in the same patch. One of them is that the numa parameter is now visible in "query-command-line-options", the second one is that it enabled using disjoint cpu ranges for -numa specification. This will be used in later patch. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-06-17 11:43:19 +00:00
"numa",
qemu: Implement ./hugepages/page/[@size, @unit, @nodeset] Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-07-23 15:37:21 +00:00
"memory-backend-file",
conf: Add USB sound card support and implement it for qemu
2014-07-24 15:32:31 +00:00
"usb-audio",
qemu: Issue rtc-reset-reinjection command after guest-set-time https://bugzilla.redhat.com/show_bug.cgi?id=1103245 An advice appeared there on the qemu-devel list [1]. When a domain is suspended and then resumed guest kernel is not aware of this. So we've introduced virDomainSetTime API that resets the time within guest using qemu-ga. On the other hand, qemu itself is trying to make RTC beat faster to catch the difference. But if we don't tell qemu that guest's time was reset via the other method, both mechanisms are applied resulting in again wrong guest time. In order to avoid summing both corrections we need to tell qemu that it should not use the RTC injection if the guest time is set via guest agent. 1: http://www.mail-archive.com/qemu-devel@nongnu.org/msg236435.html Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-08-13 12:28:24 +00:00
"rtc-reset-reinjection",
qemu: add capability probing for splash-timeout Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-08-22 11:42:46 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 175 */
"splash-timeout",
qemu: Add support for iothreads Add a new capability to ensure the iothreads feature exists for the qemu emulator being run - requires the "query-iothreads" QMP command. Using the domain XML add correspoding command argument in order to generate the threads. The iothreads will use a name space "iothread#" where, the future patch to add support for using an iothread to a disk definition to merely define which of the available threads to use. Add tests to ensure the xml/argv processing is correct. Note that no change was made to qemuargv2xmltest.c as processing the -object element would require knowing more than just iothreads.
2014-08-22 22:15:30 +00:00
"iothread",
qemu: Add RDMA migration capabilities
2014-09-11 12:11:54 +00:00
"migrate-rdma",
qemu: add capability probing for ivshmem device Ivshmem is supported by QEMU since 0.13 release. Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com> Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-08-22 10:47:02 +00:00
"ivshmem",
qemu: Add Qemu capability for bps_max and friends Add the capability to detect if the qemu binary have the capability to use bps_max and friends Add a value in the enum virQEMUCapsFlags for the qemu capability. Set it with virQEMUCapsSet if the binary suport bps_max and they friends. Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com>
2014-10-29 12:16:01 +00:00
"drive-iotune-max",
caps: introduce new QEMU capability for vgamem_mb device property Allow setting vgamem size for video devices. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-11-12 12:58:33 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 180 */
"VGA.vgamem_mb",
caps: introduce new QEMU capability for vgamem_mb device property Allow setting vgamem size for video devices. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-11-12 12:58:33 +00:00
"vmware-svga.vgamem_mb",
"qxl.vgamem_mb",
"qxl-vga.vgamem_mb",
qemu: caps: Add capability bit for the "pc-dimm" device The pc-dimm device represents a RAM memory module.
2014-10-06 12:16:47 +00:00
"pc-dimm",
qemu: add QEMU_CAPS_MACHINE_VMPORT_OPT Set the capability based on qmp query, or qemu version. The qmp query includes vmport with 2.2, but no longer with 2.3. It lists only non-machine specific capabilities, so check the qemu version too until a machine-specific query is supported.
2015-04-02 16:43:47 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 185 */
"machine-vmport-opt",
libvirt: qemu: enable/disable protected key management ops Introduces two new -machine option parameters to the QEMU command to enable/disable the CPACF protected key management operations for a guest: aes-key-wrap='on|off' dea-key-wrap='on|off' The QEMU code maps the corresponding domain configuration elements to the QEMU -machine option parameters to create the QEMU command: <cipher name='aes' state='on'> --> aes-key-wrap=on <cipher name='aes' state='off'> --> aes-key-wrap=off <cipher name='dea' state='on'> --> dea-key-wrap=on <cipher name='dea' state='off'> --> dea-key-wrap=off Signed-off-by: Tony Krowiak <akrowiak@linux.vnet.ibm.com> Signed-off-by: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-04-27 21:57:29 +00:00
"aes-key-wrap",
"dea-key-wrap",
qemu: Implement pci-serial https://bugzilla.redhat.com/show_bug.cgi?id=998813 Implementation is pretty straight-forward. Of course, not all qemus out there supports the device, so new capability is introduced and checked prior each use of the device. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-05-06 15:50:03 +00:00
"pci-serial",
qemu: command: Support arm 32-on-64 KVM with -cpu aarch64=off qemu 2.3.0 added the -cpu host,aarch64=off option, which allows using qemu-system-aarch64 KVM to run armv7l VMs. Add a capabilities check for it, wire it up in qemu_command, and test the command line generation.
2015-05-21 22:18:20 +00:00
"aarch64-off",
qemu: Add capability for vhost-user multiqueue The support for this was added in QEMU with commit 830d70db692e374b55555f4407f96a1ceefdcc97. Unfortunately we have to do another ugly version-based capability check. The other option would be not to check for the capability at all and leave that to qemu as it's done with multiqueue tap devices. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-06-04 09:37:37 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 190 */
"vhost-user-multiqueue",
qemu_monitor: Wire up MIGRATION event Thanks to Juan's work QEMU finally emits an event whenever migration state changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-05-28 11:35:52 +00:00
"migration-event",
qemu: Introduce QEMU_CAPS_OBJECT_GPEX This capability specifies that qemu can implement generic PCI host controller. It is often used for virtual environments, including ARM. Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
2015-07-17 11:27:44 +00:00
"gpex-pcihost",
qemu: add capabilities bit for device ioh3420 This is a PCIE "root port". It connects only to a port of the integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and provides a single PCIe port that can have PCI or PCIe devices hotplugged into it. This device will be used to implement the "pcie-root-port" model of pci controller.
2015-06-17 17:13:28 +00:00
"ioh3420",
qemu: add capabilities bit for device x3130-upstream This is the upstream part of a PCIe switch. It connects to a PCIe port (but not PCI) on the upstream side, and can have up to 31 xio3130-downstream controllers (but no other types of devices) connected to its downstream side. This device will be used to implement the "pcie-switch-upstream-port" model of pci controller.
2015-06-16 18:54:21 +00:00
"x3130-upstream",
qemu: Introduce QEMU_CAPS_DEVICE_RTL8139 This capability can be used to detect whether or not the QEMU binary supports the rtl8139 network device.
2015-09-04 14:23:46 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 195 */
"xio3130-downstream",
qemu: Introduce QEMU_CAPS_DEVICE_RTL8139 This capability can be used to detect whether or not the QEMU binary supports the rtl8139 network device.
2015-09-04 14:23:46 +00:00
"rtl8139",
qemu: Introduce QEMU_CAPS_DEVICE_E1000 This capability can be used to detect whether or not the QEMU binary supports the e1000 network device.
2015-09-04 14:40:37 +00:00
"e1000",
qemu: Introduce QEMU_CAPS_DEVICE_VIRTIO_NET This capability can be used to detect whether or not the QEMU binary supports the virtio-net-* network device.
2015-09-01 12:38:19 +00:00
"virtio-net",
qemu: Introduce QEMU_CAPS_MACH_VIRT_GIC_VERSION capability Unfortunately qemu currently doesn't offer introspection for machine types, so we have to rely on version number, similar to QEMU_CAPS_MACHINE_USB_OPT. Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
2015-09-30 11:04:09 +00:00
"gic-version",
qemu: Use -incoming defer for migrations Traditionally, we pass incoming migration URI on QEMU command line, which has some drawbacks. Depending on the URI QEMU may initialize its migration state immediately without giving us a chance to set any additional migration parameters (this applies mainly for fd: URIs). For some URIs the monitor may be completely blocked from the beginning until migration is finished, which means we may be stuck in qmp_capabilities command without being able to send any QMP commands. QEMU solved this by introducing "defer" parameter for -incoming command line option. This will tell QEMU to prepare for an incoming migration while the actual incoming URI is sent using migrate-incoming QMP command. Before calling this command we can normally talk to the monitor and even set any migration parameters which will be honored by the incoming migration. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-11-11 17:02:23 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 200 */
"incoming-defer",
qemu: add virtio video device qemu 2.5 provides virtio video device. It can be used with -device virtio-vga for primary devices, or -device virtio-gpu for non-vga devices. However, only the primary device (VGA) is supported with this patch. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1195176 Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-11-25 08:42:32 +00:00
"virtio-gpu",
qemu: add virtio-gpu virgl support Check if virtio-gpu provides virgl option, and add qemu command line formatter. It is enabled with the existing accel3d attribute: <model type='virtio' heads='1'> <acceleration accel3d='yes'/> </model> Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-11-25 08:42:33 +00:00
"virtio-gpu.virgl",
qemu: add capabilities for virtio input devices Add capabilities for virtio-keyboard, virtio-mouse and virtio-tablet devices: name "virtio-keyboard-device", bus virtio-bus name "virtio-keyboard-pci", bus PCI name "virtio-mouse-device", bus virtio-bus name "virtio-mouse-pci", bus PCI name "virtio-tablet-device", bus virtio-bus name "virtio-tablet-pci", bus PCI Map both -device and -pci versions of the device to one capability. https://bugzilla.redhat.com/show_bug.cgi?id=1231114
2015-11-13 10:26:37 +00:00
"virtio-keyboard",
"virtio-mouse",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 205 */
"virtio-tablet",
qemu: add capability for virtio-input-host-device Add QEMU_CAPS_VIRTIO_INPUT_HOST for both virtio-input-host-device and virtio-input-host-pci.
2015-11-13 14:41:20 +00:00
"virtio-input-host",
qemu: Process new 'append' attribute for char dev with output to a file By default, QEMU truncates serial file on open. Sometimes, it could be weird - for example, when we are trying to investigate some event, which occured several restarts ago. This patch adds an ability to preserve previous content. Signed-off-by: Dmitry Mishin <dim@virtuozzo.com>
2015-12-24 14:27:55 +00:00
"chardev-file-append",
qemu: caps: check for q35/ICH9 disable S3/S4 Update test data to match
2016-01-09 20:58:50 +00:00
"ich9-disable-s3",
"ich9-disable-s4",
qemu: Introduce QEMU_CAPS_VSERPORT_CHANGE This capability tells if qemu is capable of vserport_change events. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-01-05 13:05:15 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 210 */
"vserport-change-event",
qemu: add capability check for memballoon 'deflate-on-oom' feature Add appropriate capability check and new virQEMUCaps flag for the new virtio balloon feature. QEMU commit with the complete feature description: http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0dc14d841b80
2016-01-08 10:45:06 +00:00
"virtio-balloon-pci.deflate-on-oom",
qemu: add support for LSI SAS1068 (aka MPT Fusion) SCSI controller This does nothing more than adding the new device and capability. The device is present since QEMU 2.6.0. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-02-11 10:48:20 +00:00
"mptsas1068",
qemu: add spice opengl support Add Spice graphics gl attribute. qemu 2.6 should have -spice gl=on argument to enable opengl rendering context (patches on the ML). This is necessary to actually enable virgl rendering. Add a qemuxml2argv test for virtio-gpu + spice with virgl. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-02-19 14:30:15 +00:00
"spice-gl",
qemu_capabilities: introduce QEMU_CAPS_QXL(_VGA)_VRAM64 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-03-01 12:46:37 +00:00
"qxl.vram64_size_mb",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 215 */
"qxl-vga.vram64_size_mb",
qemu: add support for logging chardev output to a file Honour the <log file='...'/> element in chardevs to output data to a file. This requires QEMU >= 2.6 Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-02-23 11:56:34 +00:00
"chardev-logfile",
qemu: check for debug-threads capability QEMU (somewhere around 2.0) added a new sub-option to the -name flag -name debug-threads=on. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-03-10 19:46:38 +00:00
"debug-threads",
qemu: Add capability bit for qemu secret object Add a capability bit for the qemu secret object. Adjust the 2.6.0-1 caps/replies to add the secret object. For the .replies it's take from the '{"execute":"qom-list-types"}' output.
2016-03-21 15:49:12 +00:00
"secret",
qemu: add capabilities bit for device "pxb" The pxb device is a PCI expander bus that can be added to any 440fx-based machinetype. The PCI bus that is created has 32 standard PCI slots (hotpluggable). It can have a NUMA node number associated with it, as well as a bus number.
2016-02-24 21:40:49 +00:00
"pxb",
qemu: add capabilities bit for device "pxb-pcie" The pxb device is a PCIe expander bus that can be added to any Q35-based machinetype. A single PCIe port (*not* hotpluggable) is provided; if more than one device is desired, or if hotplug support is needed, either a pcie-root-port, or some combination of pcie-switch-upstream-port and pcie-swith-downstream-ports must be added to it. It can have a NUMA node number associated with it, as well as a bus number.
2016-03-08 21:25:22 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 220 */
"pxb-pcie",
qemu: hotplug: Skip waiting for tray opening if qemu doesn't notify us If qemu doesn't support DEVICE_TRAY_MOVED event the code that attempts to change media would attempt to re-eject the tray even if it wouldn't be notified when the tray opened. Add a capability bit and skip retrying for old qemus.
2016-04-29 11:49:13 +00:00
"device-tray-moved-event",
qemu: caps: introduce QEMU_CAPS_NEC_USB_XHCI_PORTS Reports whether we support -device nec-usb-xhci,p3=XXX value, which has been available since qemu 1.3.0
2016-04-24 14:52:38 +00:00
"nec-usb-xhci-ports",
qemu: Add capability for virtio-scsi iothreads An iothread for virtio-scsi is a property of the controller. Add a lookup of the 'virtio-scsi-pci' and 'virtio-scsi-ccw' device properties and parse the output. For both, support for the iothread was added in qemu 2.4 while support for virtio-scsi in general was added in qemu 1.4. Modify the various mock capabilities replies (by hand) to reflect the when virtio-scsi was supported and then specifically when the iothread property was added. For versions prior to 1.4, use the no device error return for virtio-scsi. For versions 1.4 to before 2.4, add some data for virtio-scsi-pci even though it isn't complete we're not looking for anything specific there anyway. For 2.4 to 2.6, add a more complete reply. Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-04-20 18:43:04 +00:00
"virtio-scsi-pci.iothread",
qemu: command: Use -name guest= if available -name guest= is the explicit parameter for passing a VM name. Using it is required to allow a VM with an '=' in the name https://bugzilla.redhat.com/show_bug.cgi?id=1276485
2016-04-22 22:39:09 +00:00
"name-guest",
qemu: Check for qxl's max_outputs parameter Add capabilities for both qxl and qxl-vga devices. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-12-11 13:26:24 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 225 */
"qxl.max_outputs",
qemu: Check for qxl's max_outputs parameter Add capabilities for both qxl and qxl-vga devices. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-12-11 13:26:24 +00:00
"qxl-vga.max_outputs",
qemu_capabilites: add QEMU_CAPS_SPICE_UNIX Add a new capability to detect support of unix sockets for spice graphics. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-06-07 22:21:29 +00:00
"spice-unix",
qemu: Add support for zero-detection writes Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-12-14 08:35:20 +00:00
"drive-detect-zeroes",
qemu: fix capability counting Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2016-08-04 15:13:48 +00:00
"tls-creds-x509",
caps: Add capability for tls-x509-creds Add the capability flag and checks for the qemu object 'tls-creds-x509' Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-06-07 15:28:20 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 230 */
"display",
Add QEMU_CAPS_DEVICE_INTEL_IOMMU Check whether QEMU supports -device intel-iommu Note that the presence of this option does not mean that it's usable because of a bug in earlier QEMU versions, but it's better than nothing. https://bugzilla.redhat.com/show_bug.cgi?id=1235580
2016-06-22 15:24:24 +00:00
"intel-iommu",
Introduce SMM feature Since its release of 2.4.0 qemu is able to enable System Management Module in the firmware, or disable it. We should expose this capability in the XML. Unfortunately, there's no good way to determine whether the binary we are talking to supports it. I mean, if qemu's run with real machine type, the smm attribute can be seen in 'qom-list /machine' output. But it's not there when qemu's run with -M none. Therefore we're stuck with version based check. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-07-13 12:09:20 +00:00
"smm",
Introduce QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY Check whether the disable-legacy property is present on the following devices: virtio-balloon-pci virtio-blk-pci virtio-scsi-pci virtio-serial-pci virtio-9p-pci virtio-net-pci virtio-rng-pci virtio-gpu-pci virtio-input-host-pci virtio-keyboard-pci virtio-mouse-pci virtio-tablet-pci Assuming that if QEMU knows other virtio devices where this property is applicable, it will have at least one of these devices. Added in QEMU by: commit e266d421490e0ae83044bbebb209b2d3650c0ba6 virtio-pci: add flags to enable/disable legacy/modern
2016-08-08 14:05:27 +00:00
"virtio-pci-disable-legacy",
qemu: Add capability for query-hotpluggable-cpus command
2016-06-23 11:56:12 +00:00
"query-hotpluggable-cpus",
qemu_capabilities: Introduce virtio-net-*.rx_queue_size Just like in the previous commit, teach qemu driver to detect whether qemu supports this configuration knob or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-08-19 06:39:08 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 235 */
"virtio-net.rx_queue_size",
qemu: fix command line building for iommu devices The intel-iommu device has existed since QEMU 2.2.0, but it was only possible to create it with -device since QEMU 2.7.0, thanks to: commit 621d983a1f9051f4cfc3f402569b46b77d8449fc Author: Marcel Apfelbaum <marcel@redhat.com> Date: Mon Jun 27 18:38:34 2016 +0300 hw/iommu: enable iommu with -device Use the standard '-device intel-iommu' to create the IOMMU device. The legacy '-machine,iommu=on' can still be used. The libvirt capability check & command line formatting code is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive. This fixes it to use iommu=on instead. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-10-03 12:31:12 +00:00
"machine-iommu",
qemu_capabilities: check for existence of virtio-vga Commit 21373feb added support for primary virtio-vga device but it was checking for virtio-gpu. Let's check for existence of virtio-vga if we want to use it. Virtio video device is currently represented by three different models *virtio-gpu-device*, *virtio-gpu-pci* and *virtio-vga*. The first two models are tied together and if virtio video devices is compiled in they both exist. However, the *virtio-vga* model doesn't have to exist on some architectures even if the first two models exist. So we cannot group all three together. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-11 12:07:58 +00:00
"virtio-vga",
caps: Add new capability for the bps/iops throttling length Add the capability to detect if the qemu binary can support the feature to use bps-max-length and friends.
2016-09-19 10:47:19 +00:00
"drive-iotune-max-length",
qemu: Add capabilities for ivshmem-{plain,doorbell} Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-08-02 06:48:45 +00:00
"ivshmem-plain",
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 240 */
"ivshmem-doorbell",
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
"query-qmp-schema",
qemu: Remove erroneously placed comments for numerical ordering Commit id '74bbb8c2ec' seems to have mismerged a bit - adding 240 comments out of place. Just clean that up.
2016-11-10 14:47:50 +00:00
"gluster.debug_level",
qemu: Introduce vhost-scsi capability Do all the stuff for the vhost-scsi capability in QEMU, so it's in place for our checks later. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2016-11-22 03:58:15 +00:00
"vhost-scsi",
caps: Add new capability for the iotune group name Add the capability to detect if the qemu binary can support the feature to use throttling.group.
2016-11-07 11:19:50 +00:00
"drive-iotune-group",
qemu: qmp query-cpu-model-expansion command query-cpu-model-expansion is used to get a list of features for a given cpu model name or to get the model and features of the host hardware/environment as seen by Qemu/kvm. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2016-12-18 19:22:26 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 245 */
"query-cpu-model-expansion",
qemu: Implement mtu on interface Not only we should set the MTU on the host end of the device but also let qemu know what MTU did we set. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-23 13:33:20 +00:00
"virtio-net.host_mtu",
qemu: add rendernode argument Add a new attribute 'rendernode' to <gl> spice element. Give it to QEMU if qemu supports it (queued for 2.9). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-02-14 21:04:13 +00:00
"spice-rendernode",
qemu: Introduce QEMU_CAPS_DEVICE_NVDIMM Introduce a qemu capability for -device nvdimm. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-07-29 06:17:42 +00:00
"nvdimm",
qemu: Add support for generic PCIe Root Ports QEMU 2.9 introduces the pcie-root-port device, which is a generic version of the existing ioh3420 device. Make the new device available to libvirt users.
2017-01-16 12:28:20 +00:00
"pcie-root-port",
qemu: skip QMP probing of CPU definitions when missing This unbreaks emulators that don't support this command such as qemu-system-mips*. Reference: http://bugs.debian.org/854125
2017-03-16 08:19:02 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 250 */
"query-cpu-definitions",
qemu: monitor: Add support for BLOCK_WRITE_THRESHOLD event The event is fired when a given block backend node (identified by the node name) experiences a write beyond the bound set via block-set-write-threshold QMP command. This wires up the monitor code to extract the data and allow us receiving the events and the capability.
2017-02-22 15:52:22 +00:00
"block-write-threshold",
qemu: capabilities: add capability for query-named-block-nodes qmp cmd
2017-03-15 16:21:48 +00:00
"query-named-block-nodes",
qemu: Add support for guest CPU cache This patch maps /domain/cpu/cache element into -cpu parameters: - <cache mode='passthrough'/> is translated to host-cache-info=on - <cache level='3' mode='emulate'/> is transformed into l3-cache=on - <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off Any other <cache> element is forbidden. The tricky part is detecting whether QEMU supports the CPU properties. The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480, earlier QEMU releases enabled host-cache-info by default and had no way to disable it. If the property is present, it defaults to 'off' for any QEMU until at least 2.9.0. The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa. Earlier versions worked as if l3-cache=off was passed. For any QEMU until at least 2.9.0 l3-cache is 'off' by default. QEMU 2.9.0 was the first release which supports probing both properties by running device-list-properties with typename=host-x86_64-cpu. Older QEMU releases did not support device-list-properties command for CPU devices. Thus we can't really rely on probing them and we can just use query-cpu-model-expansion QMP command as a witness. Because the cache property probing is only reliable for QEMU >= 2.9.0 when both are already supported for quite a few releases, we let QEMU report an error if a specific cache mode is explicitly requested. The other mode (or both if a user requested CPU cache to be disabled) is explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case the QEMU defaults change. Any older QEMU already turns them off so not doing so explicitly does not make any harm. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-25 17:07:19 +00:00
"cpu-cache",
qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Acked-by: Andrea Bolognani <abologna@redhat.com>
2017-04-28 08:44:03 +00:00
"qemu-xhci",
qemu: format kernel_irqchip on the command line Add kernel_irqchip=split/on to the QEMU command line and a capability that looks for it in query-command-line-options output. For the 'split' option, use a version check since it cannot be reasonably probed. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-03-17 07:26:49 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 255 */
"kernel-irqchip",
qemu: format kernel_irqchip on the command line Add kernel_irqchip=split/on to the QEMU command line and a capability that looks for it in query-command-line-options output. For the 'split' option, use a version check since it cannot be reasonably probed. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-03-17 07:26:49 +00:00
"kernel-irqchip.split",
qemu: format intel-iommu,intremap on the command line https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-05-03 13:23:12 +00:00
"intel-iommu.intremap",
qemu: format caching-mode on iommu command line Format the caching-mode option for the intel-iommu device, based on its <driver caching> attribute value. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-03-17 07:28:04 +00:00
"intel-iommu.caching-mode",
qemu: format eim on intel-iommu command line This option turns on extended interrupt mode, which allows more than 255 vCPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1451282 Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-05-18 08:48:03 +00:00
"intel-iommu.eim",
qemu: format device-iotlb on intel-iommu command line Format the device-iotlb attribute. https://bugzilla.redhat.com/show_bug.cgi?id=1283251 Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-05-03 15:18:47 +00:00
qemu: capabilities: Move comments separating groups of capabilities Similarly to how we specify the groups of 5 capabilities in the header file move the labels to separate line also for the VIR_ENUM_IMPL part. This simplifies rebase conflict resolution in the capability file since only lines have to be shuffled around, but they don't need to be edited.
2017-06-20 14:15:11 +00:00
/* 260 */
"intel-iommu.device-iotlb",
qemu: format virtio-related options on the command line Format iommu_platform= and ats= for virtio devices. https://bugzilla.redhat.com/show_bug.cgi?id=1283251 Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-05-24 15:09:12 +00:00
"virtio.iommu_platform",
"virtio.ats",
qemu: Introduce a new QEMU capability for -machine loadparm Add new capability for the "-machine loadparm" QEMU option. Add the capabilities replies/xml for s390x for QEMU 2.9.50. Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
2017-06-01 16:36:26 +00:00
"loadparm",
qemu: Introduce QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE This new capability can be used to detect whether a QEMU binary supports the spapr-pci-host-bridge controller. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Laine Stump <laine@laine.org>
2017-02-20 14:34:51 +00:00
"spapr-pci-host-bridge",
qemu_capabilities: Honour caps values formatting So the way we format this huge virQEMUCaps enum is we group the values in groups of five. And then at the beginning of each group we have a small comment that says what's the number of the first item in the group. Well, the last commit of 11b2ebf3e152 does not follow this formatting. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-07-22 08:30:19 +00:00
/* 265 */
qemu: capabilitity: Introduce QEMU_CAPS_SPAPR_PCI_HOST_BRIDGE_NUMA_NODE The patch adds a capability for spapr-pci-host-bridge.numa_node. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-07-21 08:02:32 +00:00
"spapr-pci-host-bridge.numa_node",
Add support for virtio-net.tx_queue_size https://bugzilla.redhat.com/show_bug.cgi?id=1462653 Just like I've added support for setting rx_queue_size (in c56cdf259 and friends), qemu just gained support for setting tx ring size. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-07-12 12:19:26 +00:00
"vnc-multi-servers",
"virtio-net.tx_queue_size",
qemu: introduce QEMU_CAPS_CHARDEV_RECONNECT Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-08-09 13:06:40 +00:00
"chardev-reconnect",
qemu: Add capabilities for virtio-vga/gpu's max_outputs= parameter Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-08-23 12:06:17 +00:00
"virtio-gpu.max_outputs",
qemu: Detect support for vxhs Using the query-qmp-schema introspection - look for the 'vxhs' blockdevOptions type. NB: This is a "best effort" type situation as there is not a mechanism to determine whether the running QEMU has been built with '--enable-vxhs'. All we can do is check if the option to use vxhs for a blockdev-add exists in the command infrastructure which does not take that into account when building its table of commands and options. Signed-off-by: John Ferlan <jferlan@redhat.com>
2017-08-29 22:44:19 +00:00
/* 270 */
"vxhs",
qemucapstest: Update test data for 'num-queues' property of virtio-blk Signed-off-by: Lin Ma <lma@suse.com>
2017-09-30 17:15:35 +00:00
"virtio-blk.num-queues",
qemu: Enable configuration of HPT resizing for pSeries guests Most of the time it's okay to leave this up to negotiation between the guest and the host, but in some situations it can be useful to manually decide the behavior, especially to enforce its availability. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1308743 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-11-06 15:39:40 +00:00
"machine.pseries.resize-hpt",
qemu: add vmcoreinfo support Starting from qemu 2.11, the `-device vmcoreinfo` will create a fw_cfg entry for a guest to store dump details, necessary to process kernel dump with KASLR enabled and providing additional kernel details. In essence, it is similar to -fw_cfg name=etc/vmcoreinfo,file=X but in this case it is not backed by a file, but collected by QEMU itself. Since the device is a singleton and shouldn't use additional hardware resources, it is presented as a <feature> element in the libvirt domain XML. The device is arm/x86 only for now (targets that support fw_cfg+dma). Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1395248 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-11-16 16:49:38 +00:00
"vmcoreinfo",
qemu: Add QEMU_CAPS_DEVICE_SPAPR_VTY Up until now we assumed the spapr-vty device would always be present, which is not very nice. Check for its availability before using it instead. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-11-08 18:13:28 +00:00
"spapr-vty",
qemu: add QEMU_CAPS_DEVICE_SCLPLMCONSOLE Add a separate capability for the sclplmconsole device, and check it specifically instead of using QEMU_CAPS_DEVICE_SCLPCONSOLE for that too. Signed-off-by: Pino Toscano <ptoscano@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-11-15 17:08:44 +00:00
/* 275 */
"sclplmconsole",
qemu_capabilities: Introcude QEMU_CAPS_NUMA_DIST This capability says if qemu is capable of specifying distances between NUMA nodes on the command line. Unfortunately, there's no real way to check this and thus we have to go with version check. QEMU introduced this in 0f203430dd8 (and friend) which was released in 2.10.0. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-11-14 13:29:20 +00:00
"numa.dist",
qemu: caps: Add capability for 'share-rw' disk option 'share-rw' for the disk device configures qemu to allow concurrent access to the backing storage. The capability is checked in various supported disk frontend buses since it does not make sense to partially backport it.
2017-11-15 14:02:58 +00:00
"disk-share-rw",
qemu: Get capabilities to use iscsi password-secret argument Detect the capability via the query-qmp-schema for blockdev-add to find the 'password-secret' parameter that will allow the iSCSI code to use the master secret object to encrypt the secret for an and only need to provide the object id of the secret on the command line thus obsfuscating the passphrase.
2017-09-01 19:09:29 +00:00
"iscsi.password-secret",
qemu: Add QEMU_CAPS_DEVICE_ISA_SERIAL All serial devices shoule have an associated capability. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-11-26 16:19:46 +00:00
"isa-serial",
qemu: Add QEMU_CAPS_DEVICE_PL011 All serial devices shoule have an associated capability. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-11-28 10:23:26 +00:00
/* 280 */
"pl011",
qemu: Add capability for pseries machine's max-cpu-compat= parameter Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-01-05 13:47:46 +00:00
"machine.pseries.max-cpu-compat",
qemu: Add dump completed event to the capabilities Add the DUMP_COMPLETED check to the capabilities. This is the mechanism used to determine whether the dump-guest-memory command can support the "-detach" option and thus be able to wait on the event and allow for a query of the progress of the dump. Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-17 13:46:27 +00:00
"dump-completed",
qemu: Introduce a new capability for virtio-gpu-ccw QEMU on S390 (since v2.11) can support virtio-gpu-ccw device. Let's introduce a new qemu capability for the device. Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2018-03-23 17:22:38 +00:00
"virtio-gpu-ccw",
qemu: Introduce capabilities for virtio input ccw devices QEMU on S390 (since v2.11) can support virtio input ccw devices. Introduce qemu capabilities for these devices. Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2018-03-23 17:22:41 +00:00
"virtio-keyboard-ccw",
/* 285 */
"virtio-mouse-ccw",
"virtio-tablet-ccw",
qemu: caps: Add capability for LUKS encrypted qcow2 image support Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-28 11:29:11 +00:00
"qcow2-luks",
qemu: Add QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE This capability will be set when the pcie-pci-bridge device is available in the QEMU binary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-01-09 17:05:30 +00:00
"pcie-pci-bridge",
Introduce QEMU_CAPS_SECCOMP_BLACKLIST QEMU commit 1bd6152 changed the default behavior from whitelist to blacklist and introduced a few sets of system calls. Use the 'elevateprivileges' parameter of -sandbox as a witness of this change. https://bugzilla.redhat.com/show_bug.cgi?id=1492597 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-31 20:15:02 +00:00
"seccomp-blacklist",
qemu: add capability detection for query-cpus-fast Detect whether QEMU supports the QMP query-cpus-fast API and set QEMU_CAPS_QUERY_CPUS_FAST in this case. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-03-05 11:44:24 +00:00
/* 290 */
"query-cpus-fast",
qemu: caps: Add capability for 'write-cache' parameter of disk frontends QEMU translates the cache mode of a disk internally into 3 flags. 'write-cache' is a flag of the frontend while others are flag of the backing storage. Add capability which will allow expressing it via the frontend attribute. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-04-03 17:11:22 +00:00
"disk-write-cache",
qemu: caps: Add capability for TLS transport in the NBD server The NBD server in qemu supports TLS transport. Detect this capability. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-26 11:11:05 +00:00
"nbd-tls",
qemu: Extend the capabilities with tpm-crb device QEMU on x86_64 (since v2.12) can support tpm-crb devices. Introduce qemu capabilities for this device. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-04-26 17:42:17 +00:00
"tpm-crb",
qemu: Introduce pr-manager-helper capability The capability tracks if qemu has pr-manager-helper object. At this time don't actually detect if qemu has the capability. Not just yet. Only after the code is written the feature will be enabled. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-02-19 06:41:25 +00:00
"pr-manager-helper",
qemu_capabilities: Introduce QEMU_CAPS_QOM_LIST_PROPERTIES This capability tracks if qemu has "qom-list-properties" monitor command. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-20 08:31:54 +00:00
/* 295 */
"qom-list-properties",
qemu_capabilities: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD This capability tracks if memory-backend-file has discard-data attribute or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-20 08:25:49 +00:00
"memory-backend-file.discard-data",
qemu: introduce capability for virtual-css-bridge Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments which identify support for ccw devices. The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7. The QEMU_CAPS_CCW capability is based on the existence of the QEMU type. Let us also add the capability QEMU_CAPS_CCW to the tests which require support for ccw devices. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:11 +00:00
"virtual-css-bridge",
qemu: introduce vfio-ccw capability Let us introduce the capability vfio-ccw for supporting the basic channel I/O passthrough, which have been introduced in QEMU 2.10. The current focus is to support dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device. Let us also introduce the capability QEMU_CAPS_CCW_CSSID_UNRESTRICTED for virtual-css-bridge. This capability is based on the cssid-unrestricted property which exists if QEMU no longer enforces cssid restrictions based on ccw device types. Vfio-ccw capability is dependent on the hidden virtual-css-bridge, so that we are able to probe for the cssid-unrestriced property to make sure the devices are visible to non-mcss-e enabled guests. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:12 +00:00
"virtual-css-bridge.cssid-unrestricted",
"vfio-ccw",
qemu: Add QEMU_CAPS_SDL_GL to qemu capabilities Support OpenGL acceleration capability when using SDL graphics. Signed-off-by: Maciej Wolny <maciej.wolny@codethink.co.uk> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-10 10:53:58 +00:00
/* 300 */
"sdl-gl",
qemu: Introduce QEMU_CAPS_SCREENDUMP_DEVICE As of v2.12.0-rc0~32^2 QEMU is capable specifying which display device and head should the screendump be taken from. Track this capability so that we can use it later in our virDomainScreenshot API. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-05-17 09:41:37 +00:00
"screendump_device",
qemu: capabilities: Add 'hda-output' sound codec to capabilities Signed-off-by: Filip Alac <filipalac@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-05-22 11:12:33 +00:00
"hda-output",
qemu: caps: Add capability for blockdev-add/blockdev-del The capability also represents that 'blockdev-add' is functional. It's necessary to detect it via presence of 'blockdev-del' since blockdev-add did not have the unsupported 'x-blockdev-add' version previously and thus would be marked as present even if we could not use it. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-03-29 11:22:04 +00:00
"blockdev-del",
qemu: Add VM Generation ID device capability Add the query of the device objects for the vmgenid device Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-03-16 21:23:05 +00:00
"vmgenid",
Introduce QEMU_CAPS_DEVICE_VHOST_VSOCK Add a new capability flag for vhost-vsock-device https://bugzilla.redhat.com/show_bug.cgi?id=1291851 Signed-off-by: Ján Tomko <jtomko@redhat.com>
2017-11-01 15:13:27 +00:00
/* 305 */
"vhost-vsock",
qemu: probe for -chardev 'fd' parameter for FD passing QEMU >= 2.12 will support passing of pre-opened file descriptors for socket based character devices. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-14 10:34:37 +00:00
"chardev-fd-pass",
qemu: Extend QEMU capabilities with 'tpm-emulator' Extend the QEMU capabilities with tpm-emulator support. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2017-04-04 16:22:31 +00:00
"tpm-emulator",
qemu: Add capability flag for setting the extended tseg size For getting the reply I queried the newest and oldest QEMU using test/qemucapsprobe. From the differences I only extracted the reply to the new QMP command and discarded the rest. For all the versions below the one which added support for the new option I used the output from the oldest QEMU release and for those that support it I used the output from the newest one. In order to make doubly sure the reply is where it is supposed to be (the replies files are very forgiving) I added the property to all the replies files, reran the tests again and fixed the order in replies files so that all the versions are reporting the new capability. Then removed that one property. After that I used test/qemucapsfixreplies to fix the reply IDs. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-10 21:27:57 +00:00
"mch",
"mch.extended-tseg-mbytes",
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
/* 310 */
"sev-guest",
qemu: Add capability for the HPT maxpagesize feature Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-06-19 11:51:05 +00:00
"machine.pseries.cap-hpt-max-page-size",
qemu: Add capability for the HTM pSeries feature Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-06-19 11:51:05 +00:00
"machine.pseries.cap-htm",
qemu: capabilities: Add capability for werror/rerror for 'usb-device' frontend Support for specifying it with the -device frontend was added recently. Add a capability for it. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-07-09 14:35:02 +00:00
"usb-storage.werror",
qemu: caps: Introduce a capability for egl-headless Since QEMU 2.10, it's possible to use a new type of display - egl-headless which uses drm nodes to provide OpenGL support. This patch adds a capability for that. However, since QEMU doesn't provide a QMP command to probe it, we have to base the capability on specific QEMU version. Acked-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Erik Skultety <eskultet@redhat.com>
2018-06-30 14:16:24 +00:00
"egl-headless",
qemu: caps: Add vfio-pci.display capability QEMU 2.12 introduced a new vfio-pci device option 'display=on/off/auto'. This patch introduces the necessary capability. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-24 15:27:33 +00:00
/* 315 */
"vfio-pci.display",
qemu: caps: Add capability for using the blockdev infrastructure The capability currently is not enabled so that we can add individual bits first. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-03-28 15:57:14 +00:00
"blockdev",
Persist qemu capabilities in the domain status file To cope with the QEMU binary being changed while a VM is running, it is neccessary to persist the original qemu capabilities at the time the VM is booted. * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: Add an enum for a string rep of every capability * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Support for storing capabilities in the domain status XML * src/qemu/qemu_process.c: Populate & free QEMU capabilities at domain startup
2011-05-04 11:55:38 +00:00
);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
struct virQEMUCapsMachineType {
char *name;
char *alias;
unsigned int maxCpus;
qemu: capabilities: Extract availability of new cpu hotplug for machine types QEMU reports whether 'query-hotpluggable-cpus' is supported for a given machine type. Extract and cache the information using the capability cache. When copying the capabilities for a new start of qemu, mask out the presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type doesn't support hotpluggable cpus.
2016-07-29 07:45:19 +00:00
bool hotplugCpus;
qemu: record the QEMU default machine in capabilities We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 12:18:27 +00:00
bool qemuDefault;
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
};
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
typedef struct _virQEMUCapsHostCPUData virQEMUCapsHostCPUData;
typedef virQEMUCapsHostCPUData *virQEMUCapsHostCPUDataPtr;
struct _virQEMUCapsHostCPUData {
/* Only the "info" part is stored in the capabilities cache, the rest is
* re-computed from other fields and external data sources everytime we
* probe QEMU or load the cache.
*/
qemuMonitorCPUModelInfoPtr info;
/* Host CPU definition reported in domain capabilities. */
virCPUDefPtr reported;
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
/* Migratable host CPU definition used for updating guest CPU. */
virCPUDefPtr migratable;
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
/* CPU definition with features detected by libvirt using virCPUGetHost
* combined with features reported by QEMU. This is used for backward
* compatible comparison between a guest CPU and a host CPU. */
virCPUDefPtr full;
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
};
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
/*
* Update the XML parser/formatter when adding more
* information to this struct so that it gets cached
* correctly. It does not have to be ABI-stable, as
* the cache will be discarded & repopulated if the
* timestamp on the libvirtd binary changes.
qemu: Copy missing QEMU caps elements Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-04 14:48:40 +00:00
*
* And don't forget to update virQEMUCapsNewCopy.
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
*/
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
struct _virQEMUCaps {
src: Unify virObject member name Whenever we declare a new object the first member of the struct has to be virObject (or any other member of that family). Now, up until now we did not care about the name of the struct member. But lets unify it so that we can do some checks at compile time later. The unified name is 'parent'. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-13 11:51:23 +00:00
virObject parent;
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
bool usedQMP;
Introduce a API for creating QEMU capabilities for a binary Introduce a qemuCapsNewForBinary() API which creates a new QEMU capabilities object, populated with data relating to a specific QEMU binary. The qemuCaps object is also given a timestamp, which makes it possible to detect when the cached capabilities for a binary are out of date Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-10 10:47:56 +00:00
char *binary;
Change QEMU capabilities cache to check ctime instead of mtime Debian's package manager will preserve mtime timestamp on binaries from the time they are built, rather than installed. So if a user downgrades their QEMU dpkg, the libvirt capabilities cache will not refresh. The fix is to use ctime instead of mtime since it cannot be faked. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-10 15:50:19 +00:00
time_t ctime;
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
time_t libvirtCtime;
Introduce a API for creating QEMU capabilities for a binary Introduce a qemuCapsNewForBinary() API which creates a new QEMU capabilities object, populated with data relating to a specific QEMU binary. The qemuCaps object is also given a timestamp, which makes it possible to detect when the cached capabilities for a binary are out of date Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-10 10:47:56 +00:00
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
virBitmapPtr flags;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
unsigned int version;
unsigned int kvmVersion;
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
unsigned int libvirtVersion;
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
unsigned int microcodeVersion;
qemu: include libvirt & QEMU versions in QEMU log files It is often helpful to know which version of libvirt and QEMU was present when a guest was first launched. Ensure this info is written into the QEMU log file for each guest.
2015-02-02 10:28:30 +00:00
char *package;
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
char *kernelVersion;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
virArch arch;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virDomainCapsCPUModelsPtr kvmCPUModels;
virDomainCapsCPUModelsPtr tcgCPUModels;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
size_t nmachineTypes;
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
struct virQEMUCapsMachineType *machineTypes;
qemu: Probe GIC capabilities QEMU introduced the query-gic-capabilities QMP command with commit 4468d4e0f383: use the command, if available, to probe available GIC capabilities. The information obtained is stored in a virQEMUCaps instance, and will be later used to fill in a virDomainCaps instance.
2016-03-08 17:24:18 +00:00
size_t ngicCapabilities;
virGICCapability *gicCapabilities;
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
virSEVCapability *sevCapabilities;
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virQEMUCapsHostCPUData kvmCPU;
virQEMUCapsHostCPUData tcgCPU;
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
};
qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch The API may come handy if somebody has an architecture and wants to look through available qemus if the architecture is supported or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:12:07 +00:00
struct virQEMUCapsSearchData {
virArch arch;
};
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
static virClassPtr virQEMUCapsClass;
static void virQEMUCapsDispose(void *obj);
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
static int virQEMUCapsOnceInit(void)
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
{
virobject: Introduce VIR_CLASS_NEW() macro So far we are repeating the following lines over and over: if (!(virSomeObjectClass = virClassNew(virClassForObject(), "virSomeObject", sizeof(virSomeObject), virSomeObjectDispose))) return -1; While this works, it is impossible to do some checking. Firstly, the class name (the 2nd argument) doesn't match the name in the code in all cases (the 3rd argument). Secondly, the current style is needlessly verbose. This commit turns example into following: if (!(VIR_CLASS_NEW(virSomeObject, virClassForObject))) return -1; Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-17 15:42:33 +00:00
if (!VIR_CLASS_NEW(virQEMUCaps, virClassForObject()))
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
return -1;
return 0;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
VIR_ONCE_GLOBAL_INIT(virQEMUCaps)
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
static virArch virQEMUCapsArchFromString(const char *arch)
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
{
if (STREQ(arch, "i386"))
return VIR_ARCH_I686;
if (STREQ(arch, "arm"))
return VIR_ARCH_ARMV7L;
virQEMUCapsArch: openrisc vs or32 With a few exceptions, we assume that qemu binary for given architecture has form of qemu-system-$arch. Well, openrisc is yet another exception. It's binary is called qemu-system-or32. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-06-11 14:26:45 +00:00
if (STREQ(arch, "or32"))
return VIR_ARCH_OR32;
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
return virArchFromString(arch);
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
static const char *virQEMUCapsArchToString(virArch arch)
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
{
if (arch == VIR_ARCH_I686)
return "i386";
else if (arch == VIR_ARCH_ARMV7L)
return "arm";
virQEMUCapsArch: openrisc vs or32 With a few exceptions, we assume that qemu binary for given architecture has form of qemu-system-$arch. Well, openrisc is yet another exception. It's binary is called qemu-system-or32. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-06-11 14:26:45 +00:00
else if (arch == VIR_ARCH_OR32)
return "or32";
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
return virArchToString(arch);
}
qemu: Introduce virQEMUCapsGuestIsNative To have a single place where we decide whether a guest can run natively on a host. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-14 15:25:58 +00:00
/* Checks whether a domain with @guest arch can run natively on @host.
*/
qemu: Export virQEMUCapsGuestIsNative Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-07-11 13:15:01 +00:00
bool
qemu: Introduce virQEMUCapsGuestIsNative To have a single place where we decide whether a guest can run natively on a host. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-14 15:25:58 +00:00
virQEMUCapsGuestIsNative(virArch host,
virArch guest)
{
if (host == guest)
return true;
if (host == VIR_ARCH_X86_64 && guest == VIR_ARCH_I686)
return true;
if (host == VIR_ARCH_AARCH64 && guest == VIR_ARCH_ARMV7L)
return true;
if (ARCH_IS_PPC64(host) && ARCH_IS_PPC64(guest))
return true;
return false;
}
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
/* Given a host and guest architectures, find a suitable QEMU target.
*
* This is meant to be used as a second attempt if qemu-system-$guestarch
* can't be found, eg. on a x86_64 host you want to use qemu-system-i386,
* if available, instead of qemu-system-x86_64 to run i686 guests */
static virArch
virQEMUCapsFindTarget(virArch hostarch,
virArch guestarch)
{
qemu: Fix virQEMUCapsFindTarget on ppc64le virQEMUCapsFindTarget is supposed to find an alternative QEMU binary if qemu-system-$GUEST_ARCH doesn't exist. The alternative is using host architecture when it is compatible with $GUEST_ARCH. But a special treatment has to be applied for ppc64le since the QEMU binary is always called qemu-system-ppc64. Broken by me in v2.2.0-171-gf2e71550d. https://bugzilla.redhat.com/show_bug.cgi?id=1403745 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-12-13 15:58:41 +00:00
if (virQEMUCapsGuestIsNative(hostarch, guestarch))
guestarch = hostarch;
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
/* Both ppc64 and ppc64le guests can use the ppc64 target */
if (ARCH_IS_PPC64(guestarch))
guestarch = VIR_ARCH_PPC64;
return guestarch;
}
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
Make qemuCapsProbeCommand static The qemuCapsProbeCommand API is only used by the capabilities code, so can be static Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 15:05:45 +00:00
qemu: Fix up the default machine type for QMP probing The default machine type must be stored in the first element of the caps->machineTypes array. This was done for help output parsing but not for QMP probing. Added a helper function qemuSetDefaultMachine to apply the same fix up for both probing methods. Further, it was necessary to set caps->nmachineTypes after QMP probing. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2012-11-30 18:22:42 +00:00
static void
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsSetDefaultMachine(virQEMUCapsPtr qemuCaps,
size_t defIdx)
qemu: Fix up the default machine type for QMP probing The default machine type must be stored in the first element of the caps->machineTypes array. This was done for help output parsing but not for QMP probing. Added a helper function qemuSetDefaultMachine to apply the same fix up for both probing methods. Further, it was necessary to set caps->nmachineTypes after QMP probing. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2012-11-30 18:22:42 +00:00
{
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
struct virQEMUCapsMachineType tmp = qemuCaps->machineTypes[defIdx];
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
memmove(qemuCaps->machineTypes + 1,
qemuCaps->machineTypes,
sizeof(qemuCaps->machineTypes[0]) * defIdx);
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
qemuCaps->machineTypes[0] = tmp;
qemu: Fix up the default machine type for QMP probing The default machine type must be stored in the first element of the caps->machineTypes array. This was done for help output parsing but not for QMP probing. Added a helper function qemuSetDefaultMachine to apply the same fix up for both probing methods. Further, it was necessary to set caps->nmachineTypes after QMP probing. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2012-11-30 18:22:42 +00:00
}
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
static char *
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
virQEMUCapsFindBinary(const char *format,
const char *archstr)
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
{
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
char *ret = NULL;
char *binary = NULL;
PowerPC : Make 'qemu-system-ppc64' the default emulator on ppc64[le]. PowerPC : Explicitly associate 'qemu-system-ppc64' as the default emulator for all 64-bit PowerPC guests ( both Big & Little Endian ) Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
2015-02-15 04:18:00 +00:00
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
if (virAsprintf(&binary, format, archstr) < 0)
Remove redundant virFileIsExecutable check Remove unnecessary virFileIsExecutable check after virFindFileInPath. Since the commit 9ae992f virFindFileInPath will reject non-executables. Signed-off-by: Radostin Stoyanov <rstoyanov1@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-04-13 06:01:45 +00:00
return NULL;
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
ret = virFindFileInPath(binary);
VIR_FREE(binary);
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
return ret;
}
static char *
virQEMUCapsFindBinaryForArch(virArch hostarch,
virArch guestarch)
{
char *ret = NULL;
const char *archstr;
virArch target;
/* First attempt: try the guest architecture as it is */
archstr = virQEMUCapsArchToString(guestarch);
if ((ret = virQEMUCapsFindBinary("qemu-system-%s", archstr)) != NULL)
goto out;
/* Second attempt: try looking up by target instead */
target = virQEMUCapsFindTarget(hostarch, guestarch);
if (target != guestarch) {
archstr = virQEMUCapsArchToString(target);
if ((ret = virQEMUCapsFindBinary("qemu-system-%s", archstr)) != NULL)
goto out;
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
}
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
/* Third attempt, i686 only: try 'qemu' */
if (guestarch == VIR_ARCH_I686) {
if ((ret = virQEMUCapsFindBinary("%s", "qemu")) != NULL)
goto out;
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
}
Convert QEMU capabilities code to use virArch Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-11 13:06:45 +00:00
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
out:
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
return ret;
}
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
static int
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsInitGuest(virCapsPtr caps,
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virFileCachePtr cache,
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virArch hostarch,
virArch guestarch)
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
{
Convert 'int i' to 'size_t i' in src/qemu files Convert the type of loop iterators named 'i', 'j', k', 'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or 'unsigned int', also santizing 'ii', 'jj', 'kk' to use the normal 'i', 'j', 'k' naming Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
size_t i;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
char *kvmbin = NULL;
char *binary = NULL;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr qemubinCaps = NULL;
virQEMUCapsPtr kvmbinCaps = NULL;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
int ret = -1;
Various typos and misspellings
2012-10-11 16:31:20 +00:00
/* Check for existence of base emulator, or alternate base
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
* which can be used with magic cpu choice
*/
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
binary = virQEMUCapsFindBinaryForArch(hostarch, guestarch);
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
/* Ignore binary if extracting version info fails */
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
if (binary) {
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
if (!(qemubinCaps = virQEMUCapsCacheLookup(cache, binary))) {
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
virResetLastError();
VIR_FREE(binary);
}
}
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
/* qemu-kvm/kvm binaries can only be used if
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
* - host & guest arches match
qemu: caps: Advertise arm 32-on-64 KVM option We need to use qemu-system-aarch64 to run armv7l KVM VMs on an aarch64 host.
2015-05-21 22:18:30 +00:00
* - hostarch is x86_64 and guest arch is i686 (needs -cpu qemu32)
* - hostarch is aarch64 and guest arch is armv7l (needs -cpu aarch64=off)
qemu: Add conditions for qemu-kvm use on ppc64 qemu-kvm can be used to run ppc64 guests on ppc64le hosts and vice versa, since the hardware is actually the same and the endianness is chosen by the guest kernel. Up until now, however, libvirt didn't allow the use of qemu-kvm to run guests if their endianness didn't match the host's. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1267882
2015-09-30 15:58:58 +00:00
* - hostarch and guestarch are both ppc64*
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
*/
qemu: Introduce virQEMUCapsGuestIsNative To have a single place where we decide whether a guest can run natively on a host. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-14 15:25:58 +00:00
if (virQEMUCapsGuestIsNative(hostarch, guestarch)) {
qemu: caps: Advertise arm 32-on-64 KVM option We need to use qemu-system-aarch64 to run armv7l KVM VMs on an aarch64 host.
2015-05-21 22:18:30 +00:00
const char *kvmbins[] = {
"/usr/libexec/qemu-kvm", /* RHEL */
"qemu-kvm", /* Fedora */
"kvm", /* Debian/Ubuntu */
NULL,
};
/* x86 32-on-64 can be used with qemu-system-i386 and
* qemu-system-x86_64, so if we don't find a specific kvm binary,
* we can just fall back to the host arch native binary and
* everything works fine.
*
* arm is different in that 32-on-64 _only_ works with
* qemu-system-aarch64. So we have to add it to the kvmbins list
*/
qemu: Introduce virQEMUCapsGuestIsNative To have a single place where we decide whether a guest can run natively on a host. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-14 15:25:58 +00:00
if (hostarch == VIR_ARCH_AARCH64 && guestarch == VIR_ARCH_ARMV7L)
qemu: caps: Advertise arm 32-on-64 KVM option We need to use qemu-system-aarch64 to run armv7l KVM VMs on an aarch64 host.
2015-05-21 22:18:30 +00:00
kvmbins[3] = "qemu-system-aarch64";
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
for (i = 0; i < ARRAY_CARDINALITY(kvmbins); ++i) {
qemu: caps: Advertise arm 32-on-64 KVM option We need to use qemu-system-aarch64 to run armv7l KVM VMs on an aarch64 host.
2015-05-21 22:18:30 +00:00
if (!kvmbins[i])
continue;
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
kvmbin = virFindFileInPath(kvmbins[i]);
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
if (!kvmbin)
continue;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
if (!(kvmbinCaps = virQEMUCapsCacheLookup(cache, kvmbin))) {
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
virResetLastError();
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
VIR_FREE(kvmbin);
continue;
}
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
if (!binary) {
binary = kvmbin;
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
qemubinCaps = kvmbinCaps;
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
kvmbin = NULL;
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
kvmbinCaps = NULL;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
}
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
break;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
}
}
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
ret = virQEMUCapsInitGuestFromBinary(caps,
binary, qemubinCaps,
kvmbin, kvmbinCaps,
guestarch);
VIR_FREE(binary);
VIR_FREE(kvmbin);
virObjectUnref(qemubinCaps);
virObjectUnref(kvmbinCaps);
return ret;
}
int
virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
const char *binary,
virQEMUCapsPtr qemubinCaps,
const char *kvmbin,
virQEMUCapsPtr kvmbinCaps,
virArch guestarch)
{
virCapsGuestPtr guest;
bool haskvm = false;
virCapsGuestMachinePtr *machines = NULL;
size_t nmachines = 0;
int ret = -1;
bool hasdisksnapshot = false;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
if (!binary)
return 0;
qemu: Don't check for /dev/kvm presence The file being present doesn't necessarily mean anything these days, as it's created independently of whether the kvm module has been loaded[1]; moreover, we're already gathering all the information we need through QMP, so poking the filesystem at all is entirely unnecessary. [1] https://github.com/systemd/systemd/commit/d35d6249d5a7ed3228 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2018-09-14 06:43:44 +00:00
if (virQEMUCapsGet(qemubinCaps, QEMU_CAPS_KVM) ||
kvmbin)
Replace two-state local integers with bool Found with 'git grep "= 1"'.
2013-05-24 10:14:02 +00:00
haskvm = true;
qemu: Fix probing for guest capabilities Even though qemu-kvm binaries can be used in TCG mode, libvirt would only detect them if /dev/kvm was available. Thus, one would need to make a /usr/bin/qemu symlink to be able to use TCG mode with qemu-kvm in an environment without KVM support. And even though QEMU is able to make use of KVM, libvirt would not advertise KVM support unless there was a qemu-kvm symlink available. This patch fixes both issues.
2012-07-13 14:30:55 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
if (virQEMUCapsGetMachineTypesCaps(qemubinCaps, &nmachines, &machines) < 0)
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
/* We register kvm as the base emulator too, since we can
* just give -no-kvm to disable acceleration if required */
if ((guest = virCapabilitiesAddGuest(caps,
caps: Switch AddGuest to take VIR_DOMAIN_OSTYPE value Rather than an opencoded string. This should be a no-op
2015-04-17 22:09:16 +00:00
VIR_DOMAIN_OSTYPE_HVM,
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
guestarch,
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
binary,
NULL,
nmachines,
machines)) == NULL)
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
machines = NULL;
nmachines = 0;
qemu: Drop QEMU_CAPS_CPU_HOST The only QEMU versions that don't have such capability are <0.11, which we no longer support anyway
2016-05-16 08:08:29 +00:00
/* CPU selection is always available, because all QEMU versions
* we support can use at least '-cpu host' */
if (!virCapabilitiesAddGuestFeature(guest, "cpuselection", true, false))
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
qemu: capabilities: Always assume QEMU_CAPS_BOOTINDEX The field was added in qemu v0.13.0-rc0-731-g1ca4d09ae0 so all supported qemu versions now use it. There's a LOT of test fallout as we did not use capabilities close enough to upstream for many of our tests. Several tests had a 'bootindex' variant. Since they'd become redundant they are also removed here. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-08-09 11:26:17 +00:00
if (!virCapabilitiesAddGuestFeature(guest, "deviceboot", true, false))
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
qemu: Support per-device boot ordering Support for this is included in qemu and seabios from upstream git.
2011-01-12 10:33:34 +00:00
qemu: export disk snapshot support in capabilities This patch adds an element to QEMU's capability XML, to show if the underlying QEMU binary supports the live disk snapshotting or not. This allows any client to know ahead of time if the feature is available. Without this information available, the only way to check for the snapshot support is to request one and check for errors. Signed-off-by: Francesco Romani <fromani@redhat.com>
2014-03-17 15:19:44 +00:00
if (virQEMUCapsGet(qemubinCaps, QEMU_CAPS_DISK_SNAPSHOT))
hasdisksnapshot = true;
capabilities: use bool instead of int While preparing to add a capability for active commit, I noticed that the existing code was abusing int for boolean values. * src/conf/capabilities.h (_virCapsGuestFeature, _virCapsHost) (virCapabilitiesNew, virCapabilitiesAddGuestFeature): Improve types. * src/conf/capabilities.c (virCapabilitiesNew) (virCapabilitiesAddGuestFeature): Adjust signature. * src/bhyve/bhyve_capabilities.c (virBhyveCapsBuild): Update clients. * src/esx/esx_driver.c (esxCapsInit): Likewise. * src/libxl/libxl_conf.c (libxlMakeCapabilities): Likewise. * src/lxc/lxc_conf.c (virLXCDriverCapsInit): Likewise. * src/openvz/openvz_conf.c (openvzCapsInit): Likewise. * src/parallels/parallels_driver.c (parallelsBuildCapabilities): Likewise. * src/phyp/phyp_driver.c (phypCapsInit): Likewise. * src/qemu/qemu_capabilities.c (virQEMUCapsInit) (virQEMUCapsInitGuestFromBinary): Likewise. * src/security/virt-aa-helper.c (get_definition): Likewise. * src/test/test_driver.c (testBuildCapabilities): Likewise. * src/uml/uml_conf.c (umlCapsInit): Likewise. * src/vbox/vbox_tmpl.c (vboxCapsInit): Likewise. * src/vmware/vmware_conf.c (vmwareCapsInit): Likewise. * src/xen/xen_hypervisor.c (xenHypervisorBuildCapabilities): Likewise. * src/xenapi/xenapi_driver.c (getCapsObject): Likewise. * tests/qemucaps2xmltest.c (testGetCaps): Likewise. * tests/testutils.c (virTestGenericCapsInit): Likewise. * tests/testutilslxc.c (testLXCCapsInit): Likewise. * tests/testutilsqemu.c (testQemuCapsInit): Likewise. * tests/testutilsxen.c (testXenCapsInit): Likewise. * tests/vircaps2xmltest.c (buildVirCapabilities): Likewise. * tests/vircapstest.c (buildNUMATopology): Likewise. * tests/vmx2xmltest.c (testCapsInit): Likewise. * tests/xml2vmxtest.c (testCapsInit): Likewise. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-07-14 12:56:13 +00:00
if (!virCapabilitiesAddGuestFeature(guest, "disksnapshot", hasdisksnapshot,
false))
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
qemu: export disk snapshot support in capabilities This patch adds an element to QEMU's capability XML, to show if the underlying QEMU binary supports the live disk snapshotting or not. This allows any client to know ahead of time if the feature is available. Without this information available, the only way to check for the snapshot support is to request one and check for errors. Signed-off-by: Francesco Romani <fromani@redhat.com>
2014-03-17 15:19:44 +00:00
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +00:00
if (virCapabilitiesAddGuestDomain(guest,
caps: Convert to use VIR_DOMAIN_VIRT internally
2015-04-17 22:38:10 +00:00
VIR_DOMAIN_VIRT_QEMU,
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +00:00
NULL,
NULL,
0,
NULL) == NULL)
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +00:00
if (haskvm) {
virCapsGuestDomainPtr dom;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +00:00
if (kvmbin &&
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsGetMachineTypesCaps(kvmbinCaps, &nmachines, &machines) < 0)
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +00:00
if ((dom = virCapabilitiesAddGuestDomain(guest,
caps: Convert to use VIR_DOMAIN_VIRT internally
2015-04-17 22:38:10 +00:00
VIR_DOMAIN_VIRT_KVM,
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +00:00
kvmbin ? kvmbin : binary,
NULL,
nmachines,
machines)) == NULL) {
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +00:00
}
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +00:00
machines = NULL;
nmachines = 0;
qemu: Advertise ACPI support for aarch64 guests So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
2017-03-02 17:57:51 +00:00
}
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
qemu: Advertise ACPI support for aarch64 guests So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
2017-03-02 17:57:51 +00:00
if ((ARCH_IS_X86(guestarch) || guestarch == VIR_ARCH_AARCH64) &&
virCapabilitiesAddGuestFeature(guest, "acpi", true, true) == NULL) {
goto cleanup;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
}
qemu: Use ARCH_IS_X86() more In a few cases, we checked for VIR_ARCH_X86_64 and VIR_ARCH_I686 separately: change all those to use the ARCH_IS_X86() macro instead.
2017-03-02 17:00:05 +00:00
if (ARCH_IS_X86(guestarch) &&
qemu: Advertise ACPI support for aarch64 guests So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
2017-03-02 17:57:51 +00:00
virCapabilitiesAddGuestFeature(guest, "apic", true, false) == NULL) {
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
qemu: Advertise ACPI support for aarch64 guests So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
2017-03-02 17:57:51 +00:00
}
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
Convert capabilities / domain_conf to use virArch Convert the host capabilities and domain config structs to use the virArch datatype. Update the parsers and all drivers to take account of datatype change Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-10 22:28:09 +00:00
if ((guestarch == VIR_ARCH_I686) &&
capabilities: use bool instead of int While preparing to add a capability for active commit, I noticed that the existing code was abusing int for boolean values. * src/conf/capabilities.h (_virCapsGuestFeature, _virCapsHost) (virCapabilitiesNew, virCapabilitiesAddGuestFeature): Improve types. * src/conf/capabilities.c (virCapabilitiesNew) (virCapabilitiesAddGuestFeature): Adjust signature. * src/bhyve/bhyve_capabilities.c (virBhyveCapsBuild): Update clients. * src/esx/esx_driver.c (esxCapsInit): Likewise. * src/libxl/libxl_conf.c (libxlMakeCapabilities): Likewise. * src/lxc/lxc_conf.c (virLXCDriverCapsInit): Likewise. * src/openvz/openvz_conf.c (openvzCapsInit): Likewise. * src/parallels/parallels_driver.c (parallelsBuildCapabilities): Likewise. * src/phyp/phyp_driver.c (phypCapsInit): Likewise. * src/qemu/qemu_capabilities.c (virQEMUCapsInit) (virQEMUCapsInitGuestFromBinary): Likewise. * src/security/virt-aa-helper.c (get_definition): Likewise. * src/test/test_driver.c (testBuildCapabilities): Likewise. * src/uml/uml_conf.c (umlCapsInit): Likewise. * src/vbox/vbox_tmpl.c (vboxCapsInit): Likewise. * src/vmware/vmware_conf.c (vmwareCapsInit): Likewise. * src/xen/xen_hypervisor.c (xenHypervisorBuildCapabilities): Likewise. * src/xenapi/xenapi_driver.c (getCapsObject): Likewise. * tests/qemucaps2xmltest.c (testGetCaps): Likewise. * tests/testutils.c (virTestGenericCapsInit): Likewise. * tests/testutilslxc.c (testLXCCapsInit): Likewise. * tests/testutilsqemu.c (testQemuCapsInit): Likewise. * tests/testutilsxen.c (testXenCapsInit): Likewise. * tests/vircaps2xmltest.c (buildVirCapabilities): Likewise. * tests/vircapstest.c (buildNUMATopology): Likewise. * tests/vmx2xmltest.c (testCapsInit): Likewise. * tests/xml2vmxtest.c (testCapsInit): Likewise. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-07-14 12:56:13 +00:00
(virCapabilitiesAddGuestFeature(guest, "pae", true, false) == NULL ||
virCapabilitiesAddGuestFeature(guest, "nonpae", true, false) == NULL))
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
goto cleanup;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
ret = 0;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
cleanup:
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
virCapabilitiesFreeMachines(machines, nmachines);
qemu: extract guest capabilities initialization This patch decouples the binary and the capabilities detection from the guest initialization. The purpose is to make testing easier.
2014-03-17 15:19:45 +00:00
return ret;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
}
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
virCPUDefPtr
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
virQEMUCapsProbeHostCPUForEmulator(virArch hostArch,
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs All APIs which expect a list of CPU models supported by hypervisors were switched from char **models and int models to just accept a pointer to virDomainCapsCPUModels object stored in domain capabilities. This avoids the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated list of model names and also allows the various cpu driver APIs to access additional details (such as its usability) about each CPU model. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-22 13:51:33 +00:00
return virCPUGetHost(hostArch, VIR_CPU_TYPE_GUEST, NULL,
virQEMUCapsGetCPUDefinitions(qemuCaps, type));
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
}
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virCapsPtr
virQEMUCapsInit(virFileCachePtr cache)
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
{
virCapsPtr caps;
Convert 'int i' to 'size_t i' in src/qemu files Convert the type of loop iterators named 'i', 'j', k', 'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or 'unsigned int', also santizing 'ii', 'jj', 'kk' to use the normal 'i', 'j', 'k' naming Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
size_t i;
qemu: simplify use of virArchFromHost Reusing the result of virArchFromHost instead of calling it multiple times Signed-off-by: Tal Kain <tal.kain@ravellosystems.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-04-08 12:33:07 +00:00
virArch hostarch = virArchFromHost();
Convert capabilities / domain_conf to use virArch Convert the host capabilities and domain config structs to use the virArch datatype. Update the parsers and all drivers to take account of datatype change Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-10 22:28:09 +00:00
qemu: simplify use of virArchFromHost Reusing the result of virArchFromHost instead of calling it multiple times Signed-off-by: Tal Kain <tal.kain@ravellosystems.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-04-08 12:33:07 +00:00
if ((caps = virCapabilitiesNew(hostarch,
capabilities: use bool instead of int While preparing to add a capability for active commit, I noticed that the existing code was abusing int for boolean values. * src/conf/capabilities.h (_virCapsGuestFeature, _virCapsHost) (virCapabilitiesNew, virCapabilitiesAddGuestFeature): Improve types. * src/conf/capabilities.c (virCapabilitiesNew) (virCapabilitiesAddGuestFeature): Adjust signature. * src/bhyve/bhyve_capabilities.c (virBhyveCapsBuild): Update clients. * src/esx/esx_driver.c (esxCapsInit): Likewise. * src/libxl/libxl_conf.c (libxlMakeCapabilities): Likewise. * src/lxc/lxc_conf.c (virLXCDriverCapsInit): Likewise. * src/openvz/openvz_conf.c (openvzCapsInit): Likewise. * src/parallels/parallels_driver.c (parallelsBuildCapabilities): Likewise. * src/phyp/phyp_driver.c (phypCapsInit): Likewise. * src/qemu/qemu_capabilities.c (virQEMUCapsInit) (virQEMUCapsInitGuestFromBinary): Likewise. * src/security/virt-aa-helper.c (get_definition): Likewise. * src/test/test_driver.c (testBuildCapabilities): Likewise. * src/uml/uml_conf.c (umlCapsInit): Likewise. * src/vbox/vbox_tmpl.c (vboxCapsInit): Likewise. * src/vmware/vmware_conf.c (vmwareCapsInit): Likewise. * src/xen/xen_hypervisor.c (xenHypervisorBuildCapabilities): Likewise. * src/xenapi/xenapi_driver.c (getCapsObject): Likewise. * tests/qemucaps2xmltest.c (testGetCaps): Likewise. * tests/testutils.c (virTestGenericCapsInit): Likewise. * tests/testutilslxc.c (testLXCCapsInit): Likewise. * tests/testutilsqemu.c (testQemuCapsInit): Likewise. * tests/testutilsxen.c (testXenCapsInit): Likewise. * tests/vircaps2xmltest.c (buildVirCapabilities): Likewise. * tests/vircapstest.c (buildNUMATopology): Likewise. * tests/vmx2xmltest.c (testCapsInit): Likewise. * tests/xml2vmxtest.c (testCapsInit): Likewise. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-07-14 12:56:13 +00:00
true, true)) == NULL)
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
goto error;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
/* Some machines have problematic NUMA toplogy causing
* unexpected failures. We don't want to break the QEMU
* driver in this scenario, so log errors & carry on
*/
Remove src/nodeinfo There is no "node driver" as there was before, drivers have to do their own ACL checking anyway, so they all specify their functions and nodeinfo is basically just extending conf/capablities. Hence moving the code to src/conf/ is the right way to go. Also that way we can de-duplicate some code that is in virsysfs and/or virhostcpu that got duplicated during the virhostcpu.c split. And Some cleanup is done throughout the changes, like adding the vir* prefix etc. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-03-07 09:40:15 +00:00
if (virCapabilitiesInitNUMA(caps) < 0) {
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
virCapabilitiesFreeNUMAInfo(caps);
libvirt,logging: cleanup VIR_XXX0() These VIR_XXXX0 APIs make us confused, use the non-0-suffix APIs instead. How do these coversions works? The magic is using the gcc extension of ##. When __VA_ARGS__ is empty, "##" will swallow the "," in "fmt," to avoid compile error. example: origin after CPP high_level_api("%d", a_int) low_level_api("%d", a_int) high_level_api("a string") low_level_api("a string") About 400 conversions. 8 special conversions: VIR_XXXX0("") -> VIR_XXXX("msg") (avoid empty format) 2 conversions VIR_XXXX0(string_literal_with_%) -> VIR_XXXX(%->%%) 0 conversions VIR_XXXX0(non_string_literal) -> VIR_XXXX("%s", non_string_literal) (for security) 6 conversions Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
2011-05-09 09:24:09 +00:00
VIR_WARN("Failed to query host NUMA topology, disabling NUMA capabilities");
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
}
Init host cache info in drivers Added only in drivers that were already calling virCapabilitiesInitNUMA(). Instead of refactoring all the callers to behave the same way in case of error, just follow what the callers are doing for all the functions. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-03-29 13:52:31 +00:00
if (virCapabilitiesInitCaches(caps) < 0)
VIR_WARN("Failed to get host CPU cache info");
Introduce virCPUProbeHost Both QEMU and bhyve are using the same function for setting up the CPU in virCapabilities, so de-duplicate it, save code and time, and help other drivers adopt it. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-03-15 08:07:38 +00:00
if (!(caps->host.cpu = virCPUProbeHost(caps->host.arch)))
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
VIR_WARN("Failed to get host CPU");
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
Export KVM Host Power Management capabilities This patch exports KVM Host Power Management capabilities as XML so that higher-level systems management software can make use of these features available in the host. The script "pm-is-supported" (from pm-utils package) is run to discover if Suspend-to-RAM (S3) or Suspend-to-Disk (S4) is supported by the host. If either of them are supported, then a new tag "<power_management>" is introduced in the XML under the <host> tag. However in case the query to check for power management features succeeded, but the host does not support any such feature, then the XML will contain an empty <power_management/> tag. In the event that the PM query itself failed, the XML will not contain any "power_management" tag. To use this, new APIs could be implemented in libvirt to exploit power management features such as S3/S4.
2011-11-22 03:31:22 +00:00
/* Add the power management features of the host */
Remove powerMgmt_valid field from capabilities struct If we ensure that virNodeSuspendGetTargetMask always resets *bitmask to zero upon failure, there is no need for the powerMgmt_valid field. * src/util/virnodesuspend.c: Ensure *bitmask is zero upon failure * src/conf/capabilities.c, src/conf/capabilities.h: Remove powerMgmt_valid field * src/qemu/qemu_capabilities.c: Remove powerMgmt_valid
2011-11-29 14:50:04 +00:00
if (virNodeSuspendGetTargetMask(&caps->host.powerMgmt) < 0)
Export KVM Host Power Management capabilities This patch exports KVM Host Power Management capabilities as XML so that higher-level systems management software can make use of these features available in the host. The script "pm-is-supported" (from pm-utils package) is run to discover if Suspend-to-RAM (S3) or Suspend-to-Disk (S4) is supported by the host. If either of them are supported, then a new tag "<power_management>" is introduced in the XML under the <host> tag. However in case the query to check for power management features succeeded, but the host does not support any such feature, then the XML will contain an empty <power_management/> tag. In the event that the PM query itself failed, the XML will not contain any "power_management" tag. To use this, new APIs could be implemented in libvirt to exploit power management features such as S3/S4.
2011-11-22 03:31:22 +00:00
VIR_WARN("Failed to get host power management capabilities");
capabilities: Extend capabilities with iommu_support Signed-off-by: Filip Alac <filipalac@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-01 08:15:59 +00:00
/* Add IOMMU info */
virCapabilitiesHostInitIOMMU(caps);
virCaps: expose pages info There are two places where you'll find info on page sizes. The first one is under <cpu/> element, where all supported pages sizes are listed. Then the second one is under each <cell/> element which refers to concrete NUMA node. At this place, the size of page's pool is reported. So the capabilities XML looks something like this: <capabilities> <host> <uuid>01281cda-f352-cb11-a9db-e905fe22010c</uuid> <cpu> <arch>x86_64</arch> <model>Westmere</model> <vendor>Intel</vendor> <topology sockets='1' cores='1' threads='1'/> ... <pages unit='KiB' size='4'/> <pages unit='KiB' size='2048'/> <pages unit='KiB' size='1048576'/> </cpu> ... <topology> <cells num='4'> <cell id='0'> <memory unit='KiB'>4054408</memory> <pages unit='KiB' size='4'>1013602</pages> <pages unit='KiB' size='2048'>3</pages> <pages unit='KiB' size='1048576'>1</pages> <distances/> <cpus num='1'> <cpu id='0' socket_id='0' core_id='0' siblings='0'/> </cpus> </cell> <cell id='1'> <memory unit='KiB'>4071072</memory> <pages unit='KiB' size='4'>1017768</pages> <pages unit='KiB' size='2048'>3</pages> <pages unit='KiB' size='1048576'>1</pages> <distances/> <cpus num='1'> <cpu id='1' socket_id='0' core_id='0' siblings='1'/> </cpus> </cell> ... </cells> </topology> ... </host> <guest/> </capabilities> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-06 16:12:51 +00:00
/* Add huge pages info */
Change virQEMUCapsInitPages to virCapabilitiesInitPages This way more drivers can utilize the functionality without copying the code. And we can therefore test it in one place for all of them. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-03-11 15:32:13 +00:00
if (virCapabilitiesInitPages(caps) < 0)
virCaps: expose pages info There are two places where you'll find info on page sizes. The first one is under <cpu/> element, where all supported pages sizes are listed. Then the second one is under each <cell/> element which refers to concrete NUMA node. At this place, the size of page's pool is reported. So the capabilities XML looks something like this: <capabilities> <host> <uuid>01281cda-f352-cb11-a9db-e905fe22010c</uuid> <cpu> <arch>x86_64</arch> <model>Westmere</model> <vendor>Intel</vendor> <topology sockets='1' cores='1' threads='1'/> ... <pages unit='KiB' size='4'/> <pages unit='KiB' size='2048'/> <pages unit='KiB' size='1048576'/> </cpu> ... <topology> <cells num='4'> <cell id='0'> <memory unit='KiB'>4054408</memory> <pages unit='KiB' size='4'>1013602</pages> <pages unit='KiB' size='2048'>3</pages> <pages unit='KiB' size='1048576'>1</pages> <distances/> <cpus num='1'> <cpu id='0' socket_id='0' core_id='0' siblings='0'/> </cpus> </cell> <cell id='1'> <memory unit='KiB'>4071072</memory> <pages unit='KiB' size='4'>1017768</pages> <pages unit='KiB' size='2048'>3</pages> <pages unit='KiB' size='1048576'>1</pages> <distances/> <cpus num='1'> <cpu id='1' socket_id='0' core_id='0' siblings='1'/> </cpus> </cell> ... </cells> </topology> ... </host> <guest/> </capabilities> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-06 16:12:51 +00:00
VIR_WARN("Failed to get pages info");
qemu: Add RDMA migration capabilities
2014-09-11 12:11:54 +00:00
/* Add domain migration transport URIs */
virCapabilitiesAddHostMigrateTransport(caps, "tcp");
virCapabilitiesAddHostMigrateTransport(caps, "rdma");
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
Convert capabilities / domain_conf to use virArch Convert the host capabilities and domain config structs to use the virArch datatype. Update the parsers and all drivers to take account of datatype change Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-10 22:28:09 +00:00
/* QEMU can support pretty much every arch that exists,
* so just probe for them all - we gracefully fail
* if a qemu-system-$ARCH binary can't be found
*/
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < VIR_ARCH_LAST; i++)
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
if (virQEMUCapsInitGuest(caps, cache,
qemu: simplify use of virArchFromHost Reusing the result of virArchFromHost instead of calling it multiple times Signed-off-by: Tal Kain <tal.kain@ravellosystems.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-04-08 12:33:07 +00:00
hostarch,
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
i) < 0)
Refactor guest init to support qemu-system-i386 binary too Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:59:39 +00:00
goto error;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
return caps;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
error:
Turn virCapabilities into a virObject To enable virCapabilities instances to be reference counted, turn it into a virObject. All cases of virCapabilitiesFree turn into virObjectUnref Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 12:26:18 +00:00
virObjectUnref(caps);
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
return NULL;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
struct virQEMUCapsStringFlags {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
const char *value;
int flag;
};
qemu: Make probing for commands declarative
2013-06-19 08:00:10 +00:00
struct virQEMUCapsStringFlags virQEMUCapsCommands[] = {
{ "transaction", QEMU_CAPS_TRANSACTION },
qemu: better error message when block job can't succeed https://bugzilla.redhat.com/show_bug.cgi?id=1140981 reports that the qemu-kvm shipped as part of RHEL 7.0 intentionally[1] cripples block jobs by removing the 'block-stream' QMP command, while still leaving 'block-job-cancel' as an unusable no-op. Meanwhile, we already had existing code that checked whether block jobs were completely missing (such as qemu 0.15), old style (cancel is synchronous, and all commands spelled with '_'), or new style (cancel is asynchronous, and all commands spelled with '-'), and used that three-way probe to give decent error messages. At the time that code was added, all existing qemu versions fell in one of three buckets, and the code was using the presence of 'block-job-cancel' as the witness of which of the three buckets. But now that RHEL qemu has shipped with intentionally crippled 'block-stream', we have a fourth bucket, which results in ugly error messages when trying 'virsh blockpull': error: Requested operation is not valid: Command 'block-stream' is not found In reality, the fourth bucket should be treated the same as the first bucket (no block job support); we can do that by realizing that no existing build of qemu has working block-stream while lacking block-job-cancel, so it is easiest to change our witness to the command that starts a job rather than ends one. We still act correctly regarding command spelling and whether cancel is asynchronous. And on crippled RHEL builds, we now get the desired: error: unsupported configuration: block jobs not supported with this qemu binary [1] The intentional cripple is limited to qemu-kvm of RHEL; when using qemu-kvm-rhev of RHEV, block job functionality is supported. Don't ask me to explain the "why" behind it all - I'm just dealing with fallout from someone else's decision. * src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCKJOB_SYNC): Tweak comment. * src/qemu/qemu_capabilities.c (virQEMUCapsCommands): Look for stream rather than cancel when determining the flavor of block jobs supported. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-10-24 20:49:13 +00:00
{ "block-stream", QEMU_CAPS_BLOCKJOB_ASYNC },
qemu: Make probing for commands declarative
2013-06-19 08:00:10 +00:00
{ "dump-guest-memory", QEMU_CAPS_DUMP_GUEST_MEMORY },
{ "query-spice", QEMU_CAPS_SPICE },
{ "block-commit", QEMU_CAPS_BLOCK_COMMIT },
{ "query-vnc", QEMU_CAPS_VNC },
{ "drive-mirror", QEMU_CAPS_DRIVE_MIRROR },
{ "blockdev-snapshot-sync", QEMU_CAPS_DISK_SNAPSHOT },
{ "nbd-server-start", QEMU_CAPS_NBD_SERVER },
qemu: caps: Add capability for change-backing-file command This command allows to change the backing file name recorded in the metadata of a qcow (or other) image. The capability also notifies that the "block-stream" and "block-commit" commands understand the "backing-file" attribute.
2014-05-26 12:09:22 +00:00
{ "change-backing-file", QEMU_CAPS_CHANGE_BACKING_FILE },
qemu: Issue rtc-reset-reinjection command after guest-set-time https://bugzilla.redhat.com/show_bug.cgi?id=1103245 An advice appeared there on the qemu-devel list [1]. When a domain is suspended and then resumed guest kernel is not aware of this. So we've introduced virDomainSetTime API that resets the time within guest using qemu-ga. On the other hand, qemu itself is trying to make RTC beat faster to catch the difference. But if we don't tell qemu that guest's time was reset via the other method, both mechanisms are applied resulting in again wrong guest time. In order to avoid summing both corrections we need to tell qemu that it should not use the RTC injection if the guest time is set via guest agent. 1: http://www.mail-archive.com/qemu-devel@nongnu.org/msg236435.html Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-08-13 12:28:24 +00:00
{ "rtc-reset-reinjection", QEMU_CAPS_RTC_RESET_REINJECTION },
qemu: Use -incoming defer for migrations Traditionally, we pass incoming migration URI on QEMU command line, which has some drawbacks. Depending on the URI QEMU may initialize its migration state immediately without giving us a chance to set any additional migration parameters (this applies mainly for fd: URIs). For some URIs the monitor may be completely blocked from the beginning until migration is finished, which means we may be stuck in qmp_capabilities command without being able to send any QMP commands. QEMU solved this by introducing "defer" parameter for -incoming command line option. This will tell QEMU to prepare for an incoming migration while the actual incoming URI is sent using migrate-incoming QMP command. Before calling this command we can normally talk to the monitor and even set any migration parameters which will be honored by the incoming migration. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-11-11 17:02:23 +00:00
{ "migrate-incoming", QEMU_CAPS_INCOMING_DEFER },
qemu: Add capability for query-hotpluggable-cpus command
2016-06-23 11:56:12 +00:00
{ "query-hotpluggable-cpus", QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS },
qemu: qmp query-cpu-model-expansion command query-cpu-model-expansion is used to get a list of features for a given cpu model name or to get the model and features of the host hardware/environment as seen by Qemu/kvm. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2016-12-18 19:22:26 +00:00
{ "query-qmp-schema", QEMU_CAPS_QUERY_QMP_SCHEMA },
qemu: Fix virQEMUCapsCommands formatting Starting with commit id 'fab9d6e1' the formatting of: { "command-name", QEMU_CAPS_NAME }, was altered to: { "command-name", QEMU_CAPS_NAME}, and then commit id 'e2b05c9a' altered that to: { "command-name", QEMU_CAPS_NAME} So, let's just fix that up to make things consistent with the rest of the structures. Signed-off-by: John Ferlan <jferlan@redhat.com>
2018-03-20 15:45:15 +00:00
{ "query-cpu-model-expansion", QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION },
{ "query-cpu-definitions", QEMU_CAPS_QUERY_CPU_DEFINITIONS },
{ "query-named-block-nodes", QEMU_CAPS_QUERY_NAMED_BLOCK_NODES },
qemu: add capability detection for query-cpus-fast Detect whether QEMU supports the QMP query-cpus-fast API and set QEMU_CAPS_QUERY_CPUS_FAST in this case. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-03-05 11:44:24 +00:00
{ "query-cpus-fast", QEMU_CAPS_QUERY_CPUS_FAST },
qemu_capabilities: Introduce QEMU_CAPS_QOM_LIST_PROPERTIES This capability tracks if qemu has "qom-list-properties" monitor command. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-20 08:31:54 +00:00
{ "qom-list-properties", QEMU_CAPS_QOM_LIST_PROPERTIES },
qemu: caps: Add capability for blockdev-add/blockdev-del The capability also represents that 'blockdev-add' is functional. It's necessary to detect it via presence of 'blockdev-del' since blockdev-add did not have the unsupported 'x-blockdev-add' version previously and thus would be marked as present even if we could not use it. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-03-29 11:22:04 +00:00
{ "blockdev-del", QEMU_CAPS_BLOCKDEV_DEL },
qemu: Make probing for commands declarative
2013-06-19 08:00:10 +00:00
};
qemu: Add RDMA migration capabilities
2014-09-11 12:11:54 +00:00
struct virQEMUCapsStringFlags virQEMUCapsMigration[] = {
{ "rdma-pin-all", QEMU_CAPS_MIGRATE_RDMA },
};
qemu: Make probing for events declarative
2013-06-19 07:24:54 +00:00
struct virQEMUCapsStringFlags virQEMUCapsEvents[] = {
{ "BALLOON_CHANGE", QEMU_CAPS_BALLOON_EVENT },
{ "SPICE_MIGRATE_COMPLETED", QEMU_CAPS_SEAMLESS_MIGRATION },
qemu: Add support for DEVICE_DELETED event
2013-07-11 15:07:26 +00:00
{ "DEVICE_DELETED", QEMU_CAPS_DEVICE_DEL_EVENT },
qemu_monitor: Wire up MIGRATION event Thanks to Juan's work QEMU finally emits an event whenever migration state changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-05-28 11:35:52 +00:00
{ "MIGRATION", QEMU_CAPS_MIGRATION_EVENT },
qemu: Introduce QEMU_CAPS_VSERPORT_CHANGE This capability tells if qemu is capable of vserport_change events. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-01-05 13:05:15 +00:00
{ "VSERPORT_CHANGE", QEMU_CAPS_VSERPORT_CHANGE },
qemu: hotplug: Skip waiting for tray opening if qemu doesn't notify us If qemu doesn't support DEVICE_TRAY_MOVED event the code that attempts to change media would attempt to re-eject the tray even if it wouldn't be notified when the tray opened. Add a capability bit and skip retrying for old qemus.
2016-04-29 11:49:13 +00:00
{ "DEVICE_TRAY_MOVED", QEMU_CAPS_DEVICE_TRAY_MOVED },
qemu: monitor: Add support for BLOCK_WRITE_THRESHOLD event The event is fired when a given block backend node (identified by the node name) experiences a write beyond the bound set via block-set-write-threshold QMP command. This wires up the monitor code to extract the data and allow us receiving the events and the capability.
2017-02-22 15:52:22 +00:00
{ "BLOCK_WRITE_THRESHOLD", QEMU_CAPS_BLOCK_WRITE_THRESHOLD },
qemu: Add dump completed event to the capabilities Add the DUMP_COMPLETED check to the capabilities. This is the mechanism used to determine whether the dump-guest-memory command can support the "-detach" option and thus be able to wait on the event and allow for a query of the progress of the dump. Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-17 13:46:27 +00:00
{ "DUMP_COMPLETED", QEMU_CAPS_DUMP_COMPLETED },
qemu: Make probing for events declarative
2013-06-19 07:24:54 +00:00
};
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{ "hda-duplex", QEMU_CAPS_HDA_DUPLEX },
{ "hda-micro", QEMU_CAPS_HDA_MICRO },
{ "ccid-card-emulated", QEMU_CAPS_CCID_EMULATED },
{ "ccid-card-passthru", QEMU_CAPS_CCID_PASSTHRU },
{ "piix3-usb-uhci", QEMU_CAPS_PIIX3_USB_UHCI },
{ "piix4-usb-uhci", QEMU_CAPS_PIIX4_USB_UHCI },
{ "usb-ehci", QEMU_CAPS_USB_EHCI },
{ "ich9-usb-ehci1", QEMU_CAPS_ICH9_USB_EHCI1 },
{ "vt82c686b-usb-uhci", QEMU_CAPS_VT82C686B_USB_UHCI },
{ "pci-ohci", QEMU_CAPS_PCI_OHCI },
{ "nec-usb-xhci", QEMU_CAPS_NEC_USB_XHCI },
{ "usb-redir", QEMU_CAPS_USB_REDIR },
{ "usb-hub", QEMU_CAPS_USB_HUB },
{ "ich9-ahci", QEMU_CAPS_ICH9_AHCI },
{ "virtio-blk-s390", QEMU_CAPS_VIRTIO_S390 },
S390: QEMU driver support for CCW addresses This commit adds the QEMU driver support for CCW addresses. The current QEMU only allows virtio devices to be attached to the CCW bus. We named the new capability indicating that support QEMU_CAPS_VIRTIO_CCW accordingly. The fact that CCW devices can only be assigned to domains with a machine type of s390-ccw-virtio requires a few extra checks for machine type in qemu_command.c on top of querying QEMU_CAPS_VIRTIO_{CCW|S390}. The majority of the new functions deals with CCW address generation and management. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-03-05 15:44:21 +00:00
{ "virtio-blk-ccw", QEMU_CAPS_VIRTIO_CCW },
qemu: rename QEMU_CAPS_SCLP_S390 to QEMU_CAPS_DEVICE_SCLPCONSOLE Give a better name to the capability for the sclpconsole device. Signed-off-by: Pino Toscano <ptoscano@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-11-15 17:05:44 +00:00
{ "sclpconsole", QEMU_CAPS_DEVICE_SCLPCONSOLE },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{ "lsi53c895a", QEMU_CAPS_SCSI_LSI },
qemu: Rename virtio-scsi capability QEMU_CAPS_VIRTIO_SCSI_PCI implies that virtio-scsi is only supported for the PCI bus, which is not the case. Remove the _PCI suffix. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-03-14 18:32:24 +00:00
{ "virtio-scsi-pci", QEMU_CAPS_VIRTIO_SCSI },
S390: Enable virtio-scsi and virtio-rng Newer versions of QEMU support virtio-scsi and virtio-rng devices on the virtio-s390 and ccw buses. Adding capability detection, address assignment and command line generation for that. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-03-14 18:32:25 +00:00
{ "virtio-scsi-s390", QEMU_CAPS_VIRTIO_SCSI },
{ "virtio-scsi-ccw", QEMU_CAPS_VIRTIO_SCSI },
Do not require virtio-pci devices when using virtio-mmio On arm, we probe for virtio-*-pci devices, but use their virtio-*-device variants. Set the capabilities based on the -device variants as well, to make them work with qemus with the PCI devices compiled out.
2015-04-10 09:22:05 +00:00
{ "virtio-scsi-device", QEMU_CAPS_VIRTIO_SCSI },
qemu: add support for LSI MegaRAID SAS1078 (aka megasas) SCSI controller This does nothing more than adding the new device and capability. The device is present since QEMU 1.2.0. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-03-21 14:11:39 +00:00
{ "megasas", QEMU_CAPS_SCSI_MEGASAS },
qemu: add qemu vga devices caps and one cap to mark them usable QEMU_CAPS_DEVICE_QXL -device qxl QEMU_CAPS_DEVICE_VGA -device VGA QEMU_CAPS_DEVICE_CIRRUS_VGA -device cirrus-vga QEMU_CAPS_DEVICE_VMWARE_SVGA -device vmware-svga QEMU_CAPS_DEVICE_VIDEO_PRIMARY /* safe to use -device XXX for primary video device */ Fix a typo in qemuCapsObjectTypes, the string 'qxl' here should be -device qxl rather than -vga [...|qxl|..]
2012-12-14 07:06:31 +00:00
{ "qxl", QEMU_CAPS_DEVICE_QXL },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{ "sga", QEMU_CAPS_SGA },
{ "scsi-block", QEMU_CAPS_SCSI_BLOCK },
{ "scsi-cd", QEMU_CAPS_SCSI_CD },
{ "ide-cd", QEMU_CAPS_IDE_CD },
qemu: add qemu vga devices caps and one cap to mark them usable QEMU_CAPS_DEVICE_QXL -device qxl QEMU_CAPS_DEVICE_VGA -device VGA QEMU_CAPS_DEVICE_CIRRUS_VGA -device cirrus-vga QEMU_CAPS_DEVICE_VMWARE_SVGA -device vmware-svga QEMU_CAPS_DEVICE_VIDEO_PRIMARY /* safe to use -device XXX for primary video device */ Fix a typo in qemuCapsObjectTypes, the string 'qxl' here should be -device qxl rather than -vga [...|qxl|..]
2012-12-14 07:06:31 +00:00
{ "VGA", QEMU_CAPS_DEVICE_VGA },
{ "cirrus-vga", QEMU_CAPS_DEVICE_CIRRUS_VGA },
{ "vmware-svga", QEMU_CAPS_DEVICE_VMWARE_SVGA },
qemu: New cap flags for scsi-generic Adding two cap flags for scsi-generic: QEMU_CAPS_SCSI_GENERIC QEMU_CAPS_SCSI_GENERIC_BOOTINDEX Signed-off-by: Han Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: Osier Yang <jyang@redhat.com>
2013-05-03 18:07:21 +00:00
{ "usb-serial", QEMU_CAPS_DEVICE_USB_SERIAL },
qemu: Implement support for default 'random' backend for virtio-rng This patch implements support for the virtio-rng-pci device and the rng-random backend in qemu. Two capabilities bits are added to track support for those: QEMU_CAPS_DEVICE_VIRTIO_RNG - for the device support and QEMU_CAPS_OBJECT_RNG_RANDOM - for the backend support. qemu is invoked with these additional parameters if the device is enabled: -object rng-random,id=rng0,filename=/test/phile (to add the backend) -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (to add the device)
2013-01-11 16:48:21 +00:00
{ "virtio-rng-pci", QEMU_CAPS_DEVICE_VIRTIO_RNG },
S390: Enable virtio-scsi and virtio-rng Newer versions of QEMU support virtio-scsi and virtio-rng devices on the virtio-s390 and ccw buses. Adding capability detection, address assignment and command line generation for that. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-03-14 18:32:25 +00:00
{ "virtio-rng-s390", QEMU_CAPS_DEVICE_VIRTIO_RNG },
{ "virtio-rng-ccw", QEMU_CAPS_DEVICE_VIRTIO_RNG },
Do not require virtio-pci devices when using virtio-mmio On arm, we probe for virtio-*-pci devices, but use their virtio-*-device variants. Set the capabilities based on the -device variants as well, to make them work with qemus with the PCI devices compiled out.
2015-04-10 09:22:05 +00:00
{ "virtio-rng-device", QEMU_CAPS_DEVICE_VIRTIO_RNG },
qemu: Implement support for default 'random' backend for virtio-rng This patch implements support for the virtio-rng-pci device and the rng-random backend in qemu. Two capabilities bits are added to track support for those: QEMU_CAPS_DEVICE_VIRTIO_RNG - for the device support and QEMU_CAPS_OBJECT_RNG_RANDOM - for the backend support. qemu is invoked with these additional parameters if the device is enabled: -object rng-random,id=rng0,filename=/test/phile (to add the backend) -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (to add the device)
2013-01-11 16:48:21 +00:00
{ "rng-random", QEMU_CAPS_OBJECT_RNG_RANDOM },
qemu: Implement support for EGD backend for virtio-rng This patch adds a new capability bit QEMU_CAPS_OBJECT_RNG_EGD and code to support the egd backend for the VirtIO RNG device. The device is added by 3 qemu command line options: -chardev socket,id=charrng0,host=1.2.3.4,port=1234 (communication backend) -object rng-egd,chardev=charrng0,id=rng0 (RNG protocol client) -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (the RNG device)
2013-02-13 10:22:23 +00:00
{ "rng-egd", QEMU_CAPS_OBJECT_RNG_EGD },
qemu: Add command line builder and parser for NVRAM. This patch is to add command line builder and parser for NVRAM device, and add test cases. Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com>
2013-04-25 08:46:04 +00:00
{ "spapr-nvram", QEMU_CAPS_DEVICE_NVRAM },
qemu: build command line for pci-bridge device Signed-off-by: Ján Tomko <jtomko@redhat.com>
2013-03-07 11:03:41 +00:00
{ "pci-bridge", QEMU_CAPS_DEVICE_PCI_BRIDGE },
qemu: detect vfio-pci device and its bootindex parameter QEMU_CAPS_DEVICE_VFIO_PCI is set if the device named "vfio-pci" is supported in the qemu binary. QEMU_CAPS_VFIO_PCI_BOOTINDEX is set if the vfio-pci device supports the "bootindex" parameter; for some reason, the bootindex parameter wasn't included in early versions of vfio support (qemu 1.4) so we have to check for it separately from vfio itself.
2013-04-17 18:16:28 +00:00
{ "vfio-pci", QEMU_CAPS_DEVICE_VFIO_PCI },
qemu: New cap flags for scsi-generic Adding two cap flags for scsi-generic: QEMU_CAPS_SCSI_GENERIC QEMU_CAPS_SCSI_GENERIC_BOOTINDEX Signed-off-by: Han Cheng <hanc.fnst@cn.fujitsu.com> Signed-off-by: Osier Yang <jyang@redhat.com>
2013-05-03 18:07:21 +00:00
{ "scsi-generic", QEMU_CAPS_DEVICE_SCSI_GENERIC },
qemu: add dmi-to-pci-bridge controller This PCI controller, named "dmi-to-pci-bridge" in the libvirt config, and implemented with qemu's "i82801b11-bridge" device, connects to a PCI Express slot (e.g. one of the slots provided by the pcie-root controller, aka "pcie.0" on the qemu commandline), and provides 31 *non-hot-pluggable* PCI (*not* PCIe) slots, numbered 1-31. Any time a machine is defined which has a pcie-root controller (i.e. any q35-based machinetype), libvirt will automatically add a dmi-to-pci-bridge controller if one doesn't exist, and also add a pci-bridge controller. The reasoning here is that any useful domain will have either an immediate (startup time) or eventual (subsequent hot-plug) need for a standard PCI slot; since the pcie-root controller only provides PCIe slots, we need to connect a dmi-to-pci-bridge controller to it in order to get a non-hot-plug PCI slot that we can then use to connect a pci-bridge - the slots provided by the pci-bridge will be both standard PCI and hot-pluggable. Since pci-bridge devices themselves can not be hot-plugged into a running system (although you can hot-plug other devices into a pci-bridge's slots), any new pci-bridge controller that is added can (and will) be plugged into the dmi-to-pci-bridge as long as it has empty slots available. This patch is also changing the qemuxml2xml-pcie test from a "DO_TEST" to a "DO_DIFFERENT_TEST". This is so that the "before" xml can omit the automatically added dmi-to-pci-bridge and pci-bridge devices, and the "after" xml can include it - this way we are testing if libvirt is properly adding these devices.
2013-07-31 01:37:32 +00:00
{ "i82801b11-bridge", QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE },
qemu: Add capability flag for usb-storage Allow use of the usb-storage device only if the new capability flag QEMU_CAPS_DEVICE_USB_STORAGE is set, which it is for qemu(-kvm) versions >= 0.12.1.2-rhel62-beta. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2013-08-23 10:38:10 +00:00
{ "usb-storage", QEMU_CAPS_DEVICE_USB_STORAGE },
qemu: Support virtio-mmio transport for virtio on ARM Starting with qemu 1.6, the qemu-system-arm vexpress-a9 model has a hardcoded virtio-mmio transport which enables attaching all virtio devices. On the command line, we have to use virtio-XXX-device rather than virtio-XXX-pci, thankfully s390 already set the precedent here so it's fairly straight forward. At the XML level, this adds a new device address type virtio-mmio. The controller and addressing don't have any subelements at the moment because we they aren't needed for this usecase, but could be added later if needed. Add a test case for an ARM guest with one of every virtio device enabled.
2013-08-01 01:40:35 +00:00
{ "virtio-mmio", QEMU_CAPS_DEVICE_VIRTIO_MMIO },
qemu: support ich9-intel-hda audio device This resolves one of the issues in: https://bugzilla.redhat.com/show_bug.cgi?id=1003983 This device is identical to qemu's "intel-hda" device (known as "ich6" in libvirt), but has a different PCI device ID (which matches the ID of the hda audio built into the ich9 chipset, of course). It's not supported in earlier versions of qemu, so it requires a capability bit.
2013-09-24 14:17:38 +00:00
{ "ich9-intel-hda", QEMU_CAPS_DEVICE_ICH9_INTEL_HDA },
qemu: add support for -device pvpanic Map the new <panic> device in XML to the '-device pvpanic' command line of qemu. Clients can then couple the <panic> device and the <on_crash> directive to control behavior when the guest reports a panic to qemu. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-12-09 09:11:15 +00:00
{ "pvpanic", QEMU_CAPS_DEVICE_PANIC },
qemu: Add USB keyboard capability Add USB keyboard capability probing and test cases. Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2014-02-17 10:17:55 +00:00
{ "usb-kbd", QEMU_CAPS_DEVICE_USB_KBD },
qemu: memory-backend-ram capability probing The numa patch series in qemu adds "memory-backend-ram" object type by which we can tell whether we can use such objects. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-05-07 15:20:15 +00:00
{ "memory-backend-ram", QEMU_CAPS_OBJECT_MEMORY_RAM },
qemu: Implement ./hugepages/page/[@size, @unit, @nodeset] Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-07-23 15:37:21 +00:00
{ "memory-backend-file", QEMU_CAPS_OBJECT_MEMORY_FILE },
conf: Add USB sound card support and implement it for qemu
2014-07-24 15:32:31 +00:00
{ "usb-audio", QEMU_CAPS_OBJECT_USB_AUDIO },
qemu: Add support for iothreads Add a new capability to ensure the iothreads feature exists for the qemu emulator being run - requires the "query-iothreads" QMP command. Using the domain XML add correspoding command argument in order to generate the threads. The iothreads will use a name space "iothread#" where, the future patch to add support for using an iothread to a disk definition to merely define which of the available threads to use. Add tests to ensure the xml/argv processing is correct. Note that no change was made to qemuargv2xmltest.c as processing the -object element would require knowing more than just iothreads.
2014-08-22 22:15:30 +00:00
{ "iothread", QEMU_CAPS_OBJECT_IOTHREAD},
qemu: add capability probing for ivshmem device Ivshmem is supported by QEMU since 0.13 release. Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com> Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-08-22 10:47:02 +00:00
{ "ivshmem", QEMU_CAPS_DEVICE_IVSHMEM },
qemu: caps: Add capability bit for the "pc-dimm" device The pc-dimm device represents a RAM memory module.
2014-10-06 12:16:47 +00:00
{ "pc-dimm", QEMU_CAPS_DEVICE_PC_DIMM },
qemu: Implement pci-serial https://bugzilla.redhat.com/show_bug.cgi?id=998813 Implementation is pretty straight-forward. Of course, not all qemus out there supports the device, so new capability is introduced and checked prior each use of the device. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-05-06 15:50:03 +00:00
{ "pci-serial", QEMU_CAPS_DEVICE_PCI_SERIAL },
qemu: Introduce QEMU_CAPS_OBJECT_GPEX This capability specifies that qemu can implement generic PCI host controller. It is often used for virtual environments, including ARM. Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
2015-07-17 11:27:44 +00:00
{ "gpex-pcihost", QEMU_CAPS_OBJECT_GPEX},
qemu: add capabilities bit for device ioh3420 This is a PCIE "root port". It connects only to a port of the integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and provides a single PCIe port that can have PCI or PCIe devices hotplugged into it. This device will be used to implement the "pcie-root-port" model of pci controller.
2015-06-17 17:13:28 +00:00
{ "ioh3420", QEMU_CAPS_DEVICE_IOH3420 },
qemu: add capabilities bit for device x3130-upstream This is the upstream part of a PCIe switch. It connects to a PCIe port (but not PCI) on the upstream side, and can have up to 31 xio3130-downstream controllers (but no other types of devices) connected to its downstream side. This device will be used to implement the "pcie-switch-upstream-port" model of pci controller.
2015-06-16 18:54:21 +00:00
{ "x3130-upstream", QEMU_CAPS_DEVICE_X3130_UPSTREAM },
qemu: add capabilities bit for device xio3130-downstream The downstream ports of an x3130-upstream switch can each have one of these plugged into them (and that is the only place they can be connected). Each xio3130-downstream provides a single PCIe port that can have PCI or PCIe devices hotplugged into it. Apparently an entire set of x3130-upstream + several xio3130-downstreams can be hotplugged as a unit, but it's not clear to me yet how that would be done, since qemu only allows attaching a single device at a time. This device will be used to implement the "pcie-switch-downstream-port" model of pci controller.
2015-06-17 18:24:29 +00:00
{ "xio3130-downstream", QEMU_CAPS_DEVICE_XIO3130_DOWNSTREAM },
qemu: Introduce QEMU_CAPS_DEVICE_RTL8139 This capability can be used to detect whether or not the QEMU binary supports the rtl8139 network device.
2015-09-04 14:23:46 +00:00
{ "rtl8139", QEMU_CAPS_DEVICE_RTL8139 },
qemu: Introduce QEMU_CAPS_DEVICE_E1000 This capability can be used to detect whether or not the QEMU binary supports the e1000 network device.
2015-09-04 14:40:37 +00:00
{ "e1000", QEMU_CAPS_DEVICE_E1000 },
qemu: Introduce QEMU_CAPS_DEVICE_VIRTIO_NET This capability can be used to detect whether or not the QEMU binary supports the virtio-net-* network device.
2015-09-01 12:38:19 +00:00
{ "virtio-net-pci", QEMU_CAPS_DEVICE_VIRTIO_NET },
{ "virtio-net-ccw", QEMU_CAPS_DEVICE_VIRTIO_NET },
{ "virtio-net-s390", QEMU_CAPS_DEVICE_VIRTIO_NET },
{ "virtio-net-device", QEMU_CAPS_DEVICE_VIRTIO_NET },
qemu: add virtio video device qemu 2.5 provides virtio video device. It can be used with -device virtio-vga for primary devices, or -device virtio-gpu for non-vga devices. However, only the primary device (VGA) is supported with this patch. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1195176 Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-11-25 08:42:32 +00:00
{ "virtio-gpu-pci", QEMU_CAPS_DEVICE_VIRTIO_GPU },
{ "virtio-gpu-device", QEMU_CAPS_DEVICE_VIRTIO_GPU },
qemu_capabilities: check for existence of virtio-vga Commit 21373feb added support for primary virtio-vga device but it was checking for virtio-gpu. Let's check for existence of virtio-vga if we want to use it. Virtio video device is currently represented by three different models *virtio-gpu-device*, *virtio-gpu-pci* and *virtio-vga*. The first two models are tied together and if virtio video devices is compiled in they both exist. However, the *virtio-vga* model doesn't have to exist on some architectures even if the first two models exist. So we cannot group all three together. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-11 12:07:58 +00:00
{ "virtio-vga", QEMU_CAPS_DEVICE_VIRTIO_VGA },
qemu: add capabilities for virtio input devices Add capabilities for virtio-keyboard, virtio-mouse and virtio-tablet devices: name "virtio-keyboard-device", bus virtio-bus name "virtio-keyboard-pci", bus PCI name "virtio-mouse-device", bus virtio-bus name "virtio-mouse-pci", bus PCI name "virtio-tablet-device", bus virtio-bus name "virtio-tablet-pci", bus PCI Map both -device and -pci versions of the device to one capability. https://bugzilla.redhat.com/show_bug.cgi?id=1231114
2015-11-13 10:26:37 +00:00
{ "virtio-keyboard-device", QEMU_CAPS_VIRTIO_KEYBOARD },
{ "virtio-keyboard-pci", QEMU_CAPS_VIRTIO_KEYBOARD },
{ "virtio-mouse-device", QEMU_CAPS_VIRTIO_MOUSE },
{ "virtio-mouse-pci", QEMU_CAPS_VIRTIO_MOUSE },
{ "virtio-tablet-device", QEMU_CAPS_VIRTIO_TABLET },
{ "virtio-tablet-pci", QEMU_CAPS_VIRTIO_TABLET },
qemu: add capability for virtio-input-host-device Add QEMU_CAPS_VIRTIO_INPUT_HOST for both virtio-input-host-device and virtio-input-host-pci.
2015-11-13 14:41:20 +00:00
{ "virtio-input-host-device", QEMU_CAPS_VIRTIO_INPUT_HOST },
{ "virtio-input-host-pci", QEMU_CAPS_VIRTIO_INPUT_HOST },
qemu: add support for LSI SAS1068 (aka MPT Fusion) SCSI controller This does nothing more than adding the new device and capability. The device is present since QEMU 2.6.0. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-02-11 10:48:20 +00:00
{ "mptsas1068", QEMU_CAPS_SCSI_MPTSAS1068 },
qemu: Add capability bit for qemu secret object Add a capability bit for the qemu secret object. Adjust the 2.6.0-1 caps/replies to add the secret object. For the .replies it's take from the '{"execute":"qom-list-types"}' output.
2016-03-21 15:49:12 +00:00
{ "secret", QEMU_CAPS_OBJECT_SECRET },
qemu: add capabilities bit for device "pxb" The pxb device is a PCI expander bus that can be added to any 440fx-based machinetype. The PCI bus that is created has 32 standard PCI slots (hotpluggable). It can have a NUMA node number associated with it, as well as a bus number.
2016-02-24 21:40:49 +00:00
{ "pxb", QEMU_CAPS_DEVICE_PXB },
qemu: add capabilities bit for device "pxb-pcie" The pxb device is a PCIe expander bus that can be added to any Q35-based machinetype. A single PCIe port (*not* hotpluggable) is provided; if more than one device is desired, or if hotplug support is needed, either a pcie-root-port, or some combination of pcie-switch-upstream-port and pcie-swith-downstream-ports must be added to it. It can have a NUMA node number associated with it, as well as a bus number.
2016-03-08 21:25:22 +00:00
{ "pxb-pcie", QEMU_CAPS_DEVICE_PXB_PCIE },
caps: Add capability for tls-x509-creds Add the capability flag and checks for the qemu object 'tls-creds-x509' Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-06-07 15:28:20 +00:00
{ "tls-creds-x509", QEMU_CAPS_OBJECT_TLS_CREDS_X509 },
Add QEMU_CAPS_DEVICE_INTEL_IOMMU Check whether QEMU supports -device intel-iommu Note that the presence of this option does not mean that it's usable because of a bug in earlier QEMU versions, but it's better than nothing. https://bugzilla.redhat.com/show_bug.cgi?id=1235580
2016-06-22 15:24:24 +00:00
{ "intel-iommu", QEMU_CAPS_DEVICE_INTEL_IOMMU },
qemu: Add capabilities for ivshmem-{plain,doorbell} Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-08-02 06:48:45 +00:00
{ "ivshmem-plain", QEMU_CAPS_DEVICE_IVSHMEM_PLAIN },
{ "ivshmem-doorbell", QEMU_CAPS_DEVICE_IVSHMEM_DOORBELL },
qemu: Introduce vhost-scsi capability Do all the stuff for the vhost-scsi capability in QEMU, so it's in place for our checks later. Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2016-11-22 03:58:15 +00:00
{ "vhost-scsi", QEMU_CAPS_DEVICE_VHOST_SCSI },
qemu: Introduce QEMU_CAPS_DEVICE_NVDIMM Introduce a qemu capability for -device nvdimm. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-07-29 06:17:42 +00:00
{ "nvdimm", QEMU_CAPS_DEVICE_NVDIMM },
qemu: Add support for generic PCIe Root Ports QEMU 2.9 introduces the pcie-root-port device, which is a generic version of the existing ioh3420 device. Make the new device available to libvirt users.
2017-01-16 12:28:20 +00:00
{ "pcie-root-port", QEMU_CAPS_DEVICE_PCIE_ROOT_PORT },
qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Acked-by: Andrea Bolognani <abologna@redhat.com>
2017-04-28 08:44:03 +00:00
{ "qemu-xhci", QEMU_CAPS_DEVICE_QEMU_XHCI },
qemu: Introduce QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE This new capability can be used to detect whether a QEMU binary supports the spapr-pci-host-bridge controller. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Laine Stump <laine@laine.org>
2017-02-20 14:34:51 +00:00
{ "spapr-pci-host-bridge", QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE },
qemu: add vmcoreinfo support Starting from qemu 2.11, the `-device vmcoreinfo` will create a fw_cfg entry for a guest to store dump details, necessary to process kernel dump with KASLR enabled and providing additional kernel details. In essence, it is similar to -fw_cfg name=etc/vmcoreinfo,file=X but in this case it is not backed by a file, but collected by QEMU itself. Since the device is a singleton and shouldn't use additional hardware resources, it is presented as a <feature> element in the libvirt domain XML. The device is arm/x86 only for now (targets that support fw_cfg+dma). Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1395248 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-11-16 16:49:38 +00:00
{ "vmcoreinfo", QEMU_CAPS_DEVICE_VMCOREINFO },
qemu: Add QEMU_CAPS_DEVICE_SPAPR_VTY Up until now we assumed the spapr-vty device would always be present, which is not very nice. Check for its availability before using it instead. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-11-08 18:13:28 +00:00
{ "spapr-vty", QEMU_CAPS_DEVICE_SPAPR_VTY },
qemu: add QEMU_CAPS_DEVICE_SCLPLMCONSOLE Add a separate capability for the sclplmconsole device, and check it specifically instead of using QEMU_CAPS_DEVICE_SCLPCONSOLE for that too. Signed-off-by: Pino Toscano <ptoscano@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-11-15 17:08:44 +00:00
{ "sclplmconsole", QEMU_CAPS_DEVICE_SCLPLMCONSOLE },
qemu: Add QEMU_CAPS_DEVICE_ISA_SERIAL All serial devices shoule have an associated capability. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-11-26 16:19:46 +00:00
{ "isa-serial", QEMU_CAPS_DEVICE_ISA_SERIAL },
qemu: Add QEMU_CAPS_DEVICE_PL011 All serial devices shoule have an associated capability. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-11-28 10:23:26 +00:00
{ "pl011", QEMU_CAPS_DEVICE_PL011 },
qemu: Introduce a new capability for virtio-gpu-ccw QEMU on S390 (since v2.11) can support virtio-gpu-ccw device. Let's introduce a new qemu capability for the device. Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2018-03-23 17:22:38 +00:00
{ "virtio-gpu-ccw", QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW },
qemu: Introduce capabilities for virtio input ccw devices QEMU on S390 (since v2.11) can support virtio input ccw devices. Introduce qemu capabilities for these devices. Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2018-03-23 17:22:41 +00:00
{ "virtio-keyboard-ccw", QEMU_CAPS_DEVICE_VIRTIO_KEYBOARD_CCW },
{ "virtio-mouse-ccw", QEMU_CAPS_DEVICE_VIRTIO_MOUSE_CCW },
{ "virtio-tablet-ccw", QEMU_CAPS_DEVICE_VIRTIO_TABLET_CCW },
qemu: Add QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE This capability will be set when the pcie-pci-bridge device is available in the QEMU binary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-01-09 17:05:30 +00:00
{ "pcie-pci-bridge", QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE },
qemu: Detect pr-manager-helper capability Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-03-26 10:27:16 +00:00
{ "pr-manager-helper", QEMU_CAPS_PR_MANAGER_HELPER },
qemu: introduce capability for virtual-css-bridge Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments which identify support for ccw devices. The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7. The QEMU_CAPS_CCW capability is based on the existence of the QEMU type. Let us also add the capability QEMU_CAPS_CCW to the tests which require support for ccw devices. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:11 +00:00
{ "virtual-css-bridge", QEMU_CAPS_CCW },
qemu: introduce vfio-ccw capability Let us introduce the capability vfio-ccw for supporting the basic channel I/O passthrough, which have been introduced in QEMU 2.10. The current focus is to support dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device. Let us also introduce the capability QEMU_CAPS_CCW_CSSID_UNRESTRICTED for virtual-css-bridge. This capability is based on the cssid-unrestricted property which exists if QEMU no longer enforces cssid restrictions based on ccw device types. Vfio-ccw capability is dependent on the hidden virtual-css-bridge, so that we are able to probe for the cssid-unrestriced property to make sure the devices are visible to non-mcss-e enabled guests. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:12 +00:00
{ "vfio-ccw", QEMU_CAPS_DEVICE_VFIO_CCW },
qemu: capabilities: Add 'hda-output' sound codec to capabilities Signed-off-by: Filip Alac <filipalac@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-05-22 11:12:33 +00:00
{ "hda-output", QEMU_CAPS_HDA_OUTPUT },
qemu: Add VM Generation ID device capability Add the query of the device objects for the vmgenid device Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-03-16 21:23:05 +00:00
{ "vmgenid", QEMU_CAPS_DEVICE_VMGENID },
Introduce QEMU_CAPS_DEVICE_VHOST_VSOCK Add a new capability flag for vhost-vsock-device https://bugzilla.redhat.com/show_bug.cgi?id=1291851 Signed-off-by: Ján Tomko <jtomko@redhat.com>
2017-11-01 15:13:27 +00:00
{ "vhost-vsock-device", QEMU_CAPS_DEVICE_VHOST_VSOCK },
qemu: Add capability flag for setting the extended tseg size For getting the reply I queried the newest and oldest QEMU using test/qemucapsprobe. From the differences I only extracted the reply to the new QMP command and discarded the rest. For all the versions below the one which added support for the new option I used the output from the oldest QEMU release and for those that support it I used the output from the newest one. In order to make doubly sure the reply is where it is supposed to be (the replies files are very forgiving) I added the property to all the replies files, reran the tests again and fixed the order in replies files so that all the versions are reporting the new capability. Then removed that one property. After that I used test/qemucapsfixreplies to fix the reply IDs. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-10 21:27:57 +00:00
{ "mch", QEMU_CAPS_DEVICE_MCH },
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
{ "sev-guest", QEMU_CAPS_SEV_GUEST },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioBalloon[] = {
qemu: add capability check for memballoon 'deflate-on-oom' feature Add appropriate capability check and new virQEMUCaps flag for the new virtio balloon feature. QEMU commit with the complete feature description: http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0dc14d841b80
2016-01-08 10:45:06 +00:00
{ "deflate-on-oom", QEMU_CAPS_VIRTIO_BALLOON_AUTODEFLATE },
qemu: Remove virQEMUCapsProcessProps() This function was introduced in commit 41f5c2ca2776 as a way to probe the same property for multiple devices at once. Although the resulting representation is very compact, it doesn't provide any extra features compared to the existing virQEMUCapsProcessStringFlags() mechanism, which is already used for pretty much all device properties. Drop the custom function and datatypes and start using the standard ones instead. Note that, in theory, the end result is not identical because we're no longer probing properties for virtio-serial-pci virtio-9p-pci virtio-rng-pci virtio-input-host-pci virtio-keyboard-pci virtio-mouse-pci virtio-tablet-pci However, chances of any of those devices being compiled into a QEMU binary where virtio-balloon-pci virtio-blk-pci virtio-scsi-pci virtio-net-pci virtio-gpu-pci are compiled out are slim enough that it doesn't make any difference in practice, as the lack of test suite churn shows. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 13:44:49 +00:00
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS },
qemu: add capability check for memballoon 'deflate-on-oom' feature Add appropriate capability check and new virQEMUCaps flag for the new virtio balloon feature. QEMU commit with the complete feature description: http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0dc14d841b80
2016-01-08 10:45:06 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioBlk[] = {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{ "ioeventfd", QEMU_CAPS_VIRTIO_IOEVENTFD },
{ "event_idx", QEMU_CAPS_VIRTIO_BLK_EVENT_IDX },
{ "scsi", QEMU_CAPS_VIRTIO_BLK_SCSI },
{ "logical_block_size", QEMU_CAPS_BLOCKIO },
qemucapstest: Update test data for 'num-queues' property of virtio-blk Signed-off-by: Lin Ma <lma@suse.com>
2017-09-30 17:15:35 +00:00
{ "num-queues", QEMU_CAPS_VIRTIO_BLK_NUM_QUEUES },
qemu: caps: Add capability for 'share-rw' disk option 'share-rw' for the disk device configures qemu to allow concurrent access to the backing storage. The capability is checked in various supported disk frontend buses since it does not make sense to partially backport it.
2017-11-15 14:02:58 +00:00
{ "share-rw", QEMU_CAPS_DISK_SHARE_RW },
qemu: Remove virQEMUCapsProcessProps() This function was introduced in commit 41f5c2ca2776 as a way to probe the same property for multiple devices at once. Although the resulting representation is very compact, it doesn't provide any extra features compared to the existing virQEMUCapsProcessStringFlags() mechanism, which is already used for pretty much all device properties. Drop the custom function and datatypes and start using the standard ones instead. Note that, in theory, the end result is not identical because we're no longer probing properties for virtio-serial-pci virtio-9p-pci virtio-rng-pci virtio-input-host-pci virtio-keyboard-pci virtio-mouse-pci virtio-tablet-pci However, chances of any of those devices being compiled into a QEMU binary where virtio-balloon-pci virtio-blk-pci virtio-scsi-pci virtio-net-pci virtio-gpu-pci are compiled out are slim enough that it doesn't make any difference in practice, as the lack of test suite churn shows. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 13:44:49 +00:00
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS },
qemu: caps: Add capability for 'write-cache' parameter of disk frontends QEMU translates the cache mode of a disk internally into 3 flags. 'write-cache' is a flag of the frontend while others are flag of the backing storage. Add capability which will allow expressing it via the frontend attribute. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-04-03 17:11:22 +00:00
{ "write-cache", QEMU_CAPS_DISK_WRITE_CACHE },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioNet[] = {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{ "tx", QEMU_CAPS_VIRTIO_TX_ALG },
{ "event_idx", QEMU_CAPS_VIRTIO_NET_EVENT_IDX },
qemu_capabilities: Introduce virtio-net-*.rx_queue_size Just like in the previous commit, teach qemu driver to detect whether qemu supports this configuration knob or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-08-19 06:39:08 +00:00
{ "rx_queue_size", QEMU_CAPS_VIRTIO_NET_RX_QUEUE_SIZE },
Add support for virtio-net.tx_queue_size https://bugzilla.redhat.com/show_bug.cgi?id=1462653 Just like I've added support for setting rx_queue_size (in c56cdf259 and friends), qemu just gained support for setting tx ring size. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-07-12 12:19:26 +00:00
{ "tx_queue_size", QEMU_CAPS_VIRTIO_NET_TX_QUEUE_SIZE },
qemu: Implement mtu on interface Not only we should set the MTU on the host end of the device but also let qemu know what MTU did we set. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-01-23 13:33:20 +00:00
{ "host_mtu", QEMU_CAPS_VIRTIO_NET_HOST_MTU },
qemu: Remove virQEMUCapsProcessProps() This function was introduced in commit 41f5c2ca2776 as a way to probe the same property for multiple devices at once. Although the resulting representation is very compact, it doesn't provide any extra features compared to the existing virQEMUCapsProcessStringFlags() mechanism, which is already used for pretty much all device properties. Drop the custom function and datatypes and start using the standard ones instead. Note that, in theory, the end result is not identical because we're no longer probing properties for virtio-serial-pci virtio-9p-pci virtio-rng-pci virtio-input-host-pci virtio-keyboard-pci virtio-mouse-pci virtio-tablet-pci However, chances of any of those devices being compiled into a QEMU binary where virtio-balloon-pci virtio-blk-pci virtio-scsi-pci virtio-net-pci virtio-gpu-pci are compiled out are slim enough that it doesn't make any difference in practice, as the lack of test suite churn shows. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 13:44:49 +00:00
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsSpaprPCIHostBridge[] = {
qemu: capabilitity: Introduce QEMU_CAPS_SPAPR_PCI_HOST_BRIDGE_NUMA_NODE The patch adds a capability for spapr-pci-host-bridge.numa_node. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-07-21 08:02:32 +00:00
{ "numa_node", QEMU_CAPS_SPAPR_PCI_HOST_BRIDGE_NUMA_NODE },
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioSCSI[] = {
qemu: Add capability for virtio-scsi iothreads An iothread for virtio-scsi is a property of the controller. Add a lookup of the 'virtio-scsi-pci' and 'virtio-scsi-ccw' device properties and parse the output. For both, support for the iothread was added in qemu 2.4 while support for virtio-scsi in general was added in qemu 1.4. Modify the various mock capabilities replies (by hand) to reflect the when virtio-scsi was supported and then specifically when the iothread property was added. For versions prior to 1.4, use the no device error return for virtio-scsi. For versions 1.4 to before 2.4, add some data for virtio-scsi-pci even though it isn't complete we're not looking for anything specific there anyway. For 2.4 to 2.6, add a more complete reply. Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-04-20 18:43:04 +00:00
{ "iothread", QEMU_CAPS_VIRTIO_SCSI_IOTHREAD },
qemu: Remove virQEMUCapsProcessProps() This function was introduced in commit 41f5c2ca2776 as a way to probe the same property for multiple devices at once. Although the resulting representation is very compact, it doesn't provide any extra features compared to the existing virQEMUCapsProcessStringFlags() mechanism, which is already used for pretty much all device properties. Drop the custom function and datatypes and start using the standard ones instead. Note that, in theory, the end result is not identical because we're no longer probing properties for virtio-serial-pci virtio-9p-pci virtio-rng-pci virtio-input-host-pci virtio-keyboard-pci virtio-mouse-pci virtio-tablet-pci However, chances of any of those devices being compiled into a QEMU binary where virtio-balloon-pci virtio-blk-pci virtio-scsi-pci virtio-net-pci virtio-gpu-pci are compiled out are slim enough that it doesn't make any difference in practice, as the lack of test suite churn shows. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 13:44:49 +00:00
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS },
qemu: Add capability for virtio-scsi iothreads An iothread for virtio-scsi is a property of the controller. Add a lookup of the 'virtio-scsi-pci' and 'virtio-scsi-ccw' device properties and parse the output. For both, support for the iothread was added in qemu 2.4 while support for virtio-scsi in general was added in qemu 1.4. Modify the various mock capabilities replies (by hand) to reflect the when virtio-scsi was supported and then specifically when the iothread property was added. For versions prior to 1.4, use the no device error return for virtio-scsi. For versions 1.4 to before 2.4, add some data for virtio-scsi-pci even though it isn't complete we're not looking for anything specific there anyway. For 2.4 to 2.6, add a more complete reply. Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-04-20 18:43:04 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVfioPCI[] = {
qemu: caps: Add vfio-pci.display capability QEMU 2.12 introduced a new vfio-pci device option 'display=on/off/auto'. This patch introduces the necessary capability. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-24 15:27:33 +00:00
{ "display", QEMU_CAPS_VFIO_PCI_DISPLAY },
qemu: detect vfio-pci device and its bootindex parameter QEMU_CAPS_DEVICE_VFIO_PCI is set if the device named "vfio-pci" is supported in the qemu binary. QEMU_CAPS_VFIO_PCI_BOOTINDEX is set if the vfio-pci device supports the "bootindex" parameter; for some reason, the bootindex parameter wasn't included in early versions of vfio support (qemu 1.4) so we have to check for it separately from vfio itself.
2013-04-17 18:16:28 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsSCSIDisk[] = {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{ "channel", QEMU_CAPS_SCSI_DISK_CHANNEL },
{ "wwn", QEMU_CAPS_SCSI_DISK_WWN },
qemu: caps: Add capability for 'share-rw' disk option 'share-rw' for the disk device configures qemu to allow concurrent access to the backing storage. The capability is checked in various supported disk frontend buses since it does not make sense to partially backport it.
2017-11-15 14:02:58 +00:00
{ "share-rw", QEMU_CAPS_DISK_SHARE_RW },
qemu: caps: Add capability for 'write-cache' parameter of disk frontends QEMU translates the cache mode of a disk internally into 3 flags. 'write-cache' is a flag of the frontend while others are flag of the backing storage. Add capability which will allow expressing it via the frontend attribute. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-04-03 17:11:22 +00:00
{ "write-cache", QEMU_CAPS_DISK_WRITE_CACHE },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsIDEDrive[] = {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{ "wwn", QEMU_CAPS_IDE_DRIVE_WWN },
qemu: caps: Add capability for 'share-rw' disk option 'share-rw' for the disk device configures qemu to allow concurrent access to the backing storage. The capability is checked in various supported disk frontend buses since it does not make sense to partially backport it.
2017-11-15 14:02:58 +00:00
{ "share-rw", QEMU_CAPS_DISK_SHARE_RW },
qemu: caps: Add capability for 'write-cache' parameter of disk frontends QEMU translates the cache mode of a disk internally into 3 flags. 'write-cache' is a flag of the frontend while others are flag of the backing storage. Add capability which will allow expressing it via the frontend attribute. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-04-03 17:11:22 +00:00
{ "write-cache", QEMU_CAPS_DISK_WRITE_CACHE },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsPiix4PM[] = {
qemu: caps: Rename CAPS_DISABLE_S[34] to CAPS_PIIX_DISABLE_S[34] These settings are specific to PIIX, so clarify it
2016-01-04 22:57:06 +00:00
{ "disable_s3", QEMU_CAPS_PIIX_DISABLE_S3 },
{ "disable_s4", QEMU_CAPS_PIIX_DISABLE_S4 },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsUSBRedir[] = {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{ "filter", QEMU_CAPS_USB_REDIR_FILTER },
qemu: add bootindex for usb-host and usb-redir devices Allow bootindex to be specified for redirected USB devices and host USB devices. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=805414
2012-11-14 14:51:30 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsI440FXPCIHost[] = {
Build QEMU command line for pcihole64 QEMU commit 3984890 introduced the "pci-hole64-size" property, to i440FX-pcihost and q35-pcihost with a default setting of 2 GB. Translate <pcihole64>x<pcihole64/> to: -global q35-pcihost.pci-hole64-size=x for q35 machines and -global i440FX-pcihost.pci-hole64-size=x for i440FX-based machines. Error out on other machine types or if the size was specified but the pcihost device lacks 'pci-hole64-size' property. https://bugzilla.redhat.com/show_bug.cgi?id=990418
2013-08-12 11:48:34 +00:00
{ "pci-hole64-size", QEMU_CAPS_I440FX_PCI_HOLE64_SIZE },
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsQ35PCIHost[] = {
Build QEMU command line for pcihole64 QEMU commit 3984890 introduced the "pci-hole64-size" property, to i440FX-pcihost and q35-pcihost with a default setting of 2 GB. Translate <pcihole64>x<pcihole64/> to: -global q35-pcihost.pci-hole64-size=x for q35 machines and -global i440FX-pcihost.pci-hole64-size=x for i440FX-based machines. Error out on other machine types or if the size was specified but the pcihost device lacks 'pci-hole64-size' property. https://bugzilla.redhat.com/show_bug.cgi?id=990418
2013-08-12 11:48:34 +00:00
{ "pci-hole64-size", QEMU_CAPS_Q35_PCI_HOLE64_SIZE },
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsUSBStorage[] = {
qemu: Support setting the 'removable' flag for USB disks Add an attribute named 'removable' to the 'target' element of disks, which controls the removable flag. For instance, on a Linux guest it controls the value of /sys/block/$dev/removable. This option is only valid for USB disks (i.e. bus='usb'), and its default value is 'off', which is the same behaviour as before. To achieve this, 'removable=on' (or 'off') is appended to the '-device usb-storage' parameter sent to qemu when adding a USB disk via '-disk'. A capability flag QEMU_CAPS_USB_STORAGE_REMOVABLE was added to keep track if this option is supported by the qemu version used. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=922495 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2013-08-23 10:38:11 +00:00
{ "removable", QEMU_CAPS_USB_STORAGE_REMOVABLE },
qemu: caps: Add capability for 'share-rw' disk option 'share-rw' for the disk device configures qemu to allow concurrent access to the backing storage. The capability is checked in various supported disk frontend buses since it does not make sense to partially backport it.
2017-11-15 14:02:58 +00:00
{ "share-rw", QEMU_CAPS_DISK_SHARE_RW },
qemu: caps: Add capability for 'write-cache' parameter of disk frontends QEMU translates the cache mode of a disk internally into 3 flags. 'write-cache' is a flag of the frontend while others are flag of the backing storage. Add capability which will allow expressing it via the frontend attribute. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-04-03 17:11:22 +00:00
{ "write-cache", QEMU_CAPS_DISK_WRITE_CACHE },
qemu: capabilities: Add capability for werror/rerror for 'usb-device' frontend Support for specifying it with the -device frontend was added recently. Add a capability for it. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-07-09 14:35:02 +00:00
{ "werror", QEMU_CAPS_USB_STORAGE_WERROR },
qemu: Support setting the 'removable' flag for USB disks Add an attribute named 'removable' to the 'target' element of disks, which controls the removable flag. For instance, on a Linux guest it controls the value of /sys/block/$dev/removable. This option is only valid for USB disks (i.e. bus='usb'), and its default value is 'off', which is the same behaviour as before. To achieve this, 'removable=on' (or 'off') is appended to the '-device usb-storage' parameter sent to qemu when adding a USB disk via '-disk'. A capability flag QEMU_CAPS_USB_STORAGE_REMOVABLE was added to keep track if this option is supported by the qemu version used. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=922495 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2013-08-23 10:38:11 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsKVMPit[] = {
qemu: don't use deprecated -no-kvm-pit-reinjection Since qemu-kvm 1.1 [1] (since 1.3. in upstream QEMU [2]) '-no-kvm-pit-reinjection' has been deprecated. Use -global kvm-pit.lost_tick_policy=discard instead. https://bugzilla.redhat.com/show_bug.cgi?id=978719 [1] http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39 [2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f
2013-07-01 16:28:50 +00:00
{ "lost_tick_policy", QEMU_CAPS_KVM_PIT_TICK_POLICY },
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVGA[] = {
caps: introduce new QEMU capability for vgamem_mb device property Allow setting vgamem size for video devices. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-11-12 12:58:33 +00:00
{ "vgamem_mb", QEMU_CAPS_VGA_VGAMEM },
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVmwareSvga[] = {
caps: introduce new QEMU capability for vgamem_mb device property Allow setting vgamem size for video devices. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-11-12 12:58:33 +00:00
{ "vgamem_mb", QEMU_CAPS_VMWARE_SVGA_VGAMEM },
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsQxl[] = {
caps: introduce new QEMU capability for vgamem_mb device property Allow setting vgamem size for video devices. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-11-12 12:58:33 +00:00
{ "vgamem_mb", QEMU_CAPS_QXL_VGAMEM },
qemu_capabilities: introduce QEMU_CAPS_QXL(_VGA)_VRAM64 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-03-01 12:46:37 +00:00
{ "vram64_size_mb", QEMU_CAPS_QXL_VRAM64 },
qemu: Check for qxl's max_outputs parameter Add capabilities for both qxl and qxl-vga devices. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-12-11 13:26:24 +00:00
{ "max_outputs", QEMU_CAPS_QXL_MAX_OUTPUTS },
caps: introduce new QEMU capability for vgamem_mb device property Allow setting vgamem size for video devices. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-11-12 12:58:33 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsVirtioGpu[] = {
qemu_capabilities: rename QEMU_CAPS_VIRTIO_GPU_VIRGL We generally uses QEMU_CAPS_DEVICE_$NAME to probe for existence of some device and QEMU_CAPS_$NAME_$PROP to probe for existence of some property of that device. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-11 12:06:53 +00:00
{ "virgl", QEMU_CAPS_VIRTIO_GPU_VIRGL },
qemu: Add capabilities for virtio-vga/gpu's max_outputs= parameter Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-08-23 12:06:17 +00:00
{ "max_outputs", QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS },
qemu: Remove virQEMUCapsProcessProps() This function was introduced in commit 41f5c2ca2776 as a way to probe the same property for multiple devices at once. Although the resulting representation is very compact, it doesn't provide any extra features compared to the existing virQEMUCapsProcessStringFlags() mechanism, which is already used for pretty much all device properties. Drop the custom function and datatypes and start using the standard ones instead. Note that, in theory, the end result is not identical because we're no longer probing properties for virtio-serial-pci virtio-9p-pci virtio-rng-pci virtio-input-host-pci virtio-keyboard-pci virtio-mouse-pci virtio-tablet-pci However, chances of any of those devices being compiled into a QEMU binary where virtio-balloon-pci virtio-blk-pci virtio-scsi-pci virtio-net-pci virtio-gpu-pci are compiled out are slim enough that it doesn't make any difference in practice, as the lack of test suite churn shows. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 13:44:49 +00:00
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS },
qemu: add virtio-gpu virgl support Check if virtio-gpu provides virgl option, and add qemu command line formatter. It is enabled with the existing accel3d attribute: <model type='virtio' heads='1'> <acceleration accel3d='yes'/> </model> Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-11-25 08:42:33 +00:00
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsICH9[] = {
qemu: caps: check for q35/ICH9 disable S3/S4 Update test data to match
2016-01-09 20:58:50 +00:00
{ "disable_s3", QEMU_CAPS_ICH9_DISABLE_S3 },
{ "disable_s4", QEMU_CAPS_ICH9_DISABLE_S4 },
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsUSBNECXHCI[] = {
qemu: caps: introduce QEMU_CAPS_NEC_USB_XHCI_PORTS Reports whether we support -device nec-usb-xhci,p3=XXX value, which has been available since qemu 1.3.0
2016-04-24 14:52:38 +00:00
{ "p3", QEMU_CAPS_NEC_USB_XHCI_PORTS },
};
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsIntelIOMMU[] = {
qemu: format intel-iommu,intremap on the command line https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-05-03 13:23:12 +00:00
{ "intremap", QEMU_CAPS_INTEL_IOMMU_INTREMAP },
qemu: format caching-mode on iommu command line Format the caching-mode option for the intel-iommu device, based on its <driver caching> attribute value. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-03-17 07:28:04 +00:00
{ "caching-mode", QEMU_CAPS_INTEL_IOMMU_CACHING_MODE },
qemu: format eim on intel-iommu command line This option turns on extended interrupt mode, which allows more than 255 vCPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1451282 Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-05-18 08:48:03 +00:00
{ "eim", QEMU_CAPS_INTEL_IOMMU_EIM },
qemu: format device-iotlb on intel-iommu command line Format the device-iotlb attribute. https://bugzilla.redhat.com/show_bug.cgi?id=1283251 Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-05-03 15:18:47 +00:00
{ "device-iotlb", QEMU_CAPS_INTEL_IOMMU_DEVICE_IOTLB },
qemu: format intel-iommu,intremap on the command line https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-05-03 13:23:12 +00:00
};
qemu: introduce vfio-ccw capability Let us introduce the capability vfio-ccw for supporting the basic channel I/O passthrough, which have been introduced in QEMU 2.10. The current focus is to support dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device. Let us also introduce the capability QEMU_CAPS_CCW_CSSID_UNRESTRICTED for virtual-css-bridge. This capability is based on the cssid-unrestricted property which exists if QEMU no longer enforces cssid restrictions based on ccw device types. Vfio-ccw capability is dependent on the hidden virtual-css-bridge, so that we are able to probe for the cssid-unrestriced property to make sure the devices are visible to non-mcss-e enabled guests. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:12 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsVirtualCSSBridge[] = {
{ "cssid-unrestricted", QEMU_CAPS_CCW_CSSID_UNRESTRICTED },
};
qemu: Add capability flag for setting the extended tseg size For getting the reply I queried the newest and oldest QEMU using test/qemucapsprobe. From the differences I only extracted the reply to the new QMP command and discarded the rest. For all the versions below the one which added support for the new option I used the output from the oldest QEMU release and for those that support it I used the output from the newest one. In order to make doubly sure the reply is where it is supposed to be (the replies files are very forgiving) I added the property to all the replies files, reran the tests again and fixed the order in replies files so that all the versions are reporting the new capability. Then removed that one property. After that I used test/qemucapsfixreplies to fix the reply IDs. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-10 21:27:57 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsDevicePropsMCH[] = {
{ "extended-tseg-mbytes", QEMU_CAPS_MCH_EXTENDED_TSEG_MBYTES },
};
qemu: qapi: Fix naming of moved functions Change the prefix of the functions to 'virQEMUQapi' and rename the two public APIs so that the verb is put last. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-20 07:57:44 +00:00
/* see documentation for virQEMUQAPISchemaPathGet for the query format */
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsQMPSchemaQueries[] = {
qemu: capabilities: Detect support for gluster debug setting Teach qemu driver to detect whether qemu supports specifying debug level for gluster volumes. Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2016-09-21 19:34:19 +00:00
{ "blockdev-add/arg-type/options/+gluster/debug-level", QEMU_CAPS_GLUSTER_DEBUG_LEVEL},
qemu: capabilities: Add gluster.debug_level detection for 2.8.0+ Qemu 2.8.0+ changes arguments structure for blockdev-add in the effort to make it finally stable. Since libvirt recently added the detection of gluster debug support relying on the old syntax we need to add the new as well.
2016-12-06 15:59:18 +00:00
{ "blockdev-add/arg-type/+gluster/debug", QEMU_CAPS_GLUSTER_DEBUG_LEVEL},
qemu: Detect support for vxhs Using the query-qmp-schema introspection - look for the 'vxhs' blockdevOptions type. NB: This is a "best effort" type situation as there is not a mechanism to determine whether the running QEMU has been built with '--enable-vxhs'. All we can do is check if the option to use vxhs for a blockdev-add exists in the command infrastructure which does not take that into account when building its table of commands and options. Signed-off-by: John Ferlan <jferlan@redhat.com>
2017-08-29 22:44:19 +00:00
{ "blockdev-add/arg-type/+vxhs", QEMU_CAPS_VXHS},
qemu: Get capabilities to use iscsi password-secret argument Detect the capability via the query-qmp-schema for blockdev-add to find the 'password-secret' parameter that will allow the iSCSI code to use the master secret object to encrypt the secret for an and only need to provide the object id of the secret on the command line thus obsfuscating the passphrase.
2017-09-01 19:09:29 +00:00
{ "blockdev-add/arg-type/+iscsi/password-secret", QEMU_CAPS_ISCSI_PASSWORD_SECRET },
qemu: caps: Add capability for LUKS encrypted qcow2 image support Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-28 11:29:11 +00:00
{ "blockdev-add/arg-type/+qcow2/encrypt/+luks/key-secret", QEMU_CAPS_QCOW2_LUKS },
qemu: caps: Add capability for TLS transport in the NBD server The NBD server in qemu supports TLS transport. Detect this capability. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-26 11:11:05 +00:00
{ "nbd-server-start/arg-type/tls-creds", QEMU_CAPS_NBD_TLS },
qemu: Introduce QEMU_CAPS_SCREENDUMP_DEVICE As of v2.12.0-rc0~32^2 QEMU is capable specifying which display device and head should the screendump be taken from. Track this capability so that we can use it later in our virDomainScreenshot API. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-05-17 09:41:37 +00:00
{ "screendump/arg-type/device", QEMU_CAPS_SCREENDUMP_DEVICE },
qemu: capabilities: Detect active block commit via QMP schema probing if possible For versions where we can probe that the arguments are optional we can perform the probing by a schema query rather than sending a separate command to do so. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-08-14 15:53:05 +00:00
{ "block-commit/arg-type/*top", QEMU_CAPS_ACTIVE_COMMIT },
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
};
qemu_capabilities: Separate out device props fetching The code is generic enough to be reused. Move it into a separate function. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 12:39:43 +00:00
typedef struct _virQEMUCapsObjectTypeProps virQEMUCapsObjectTypeProps;
struct _virQEMUCapsObjectTypeProps {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
const char *type;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
struct virQEMUCapsStringFlags *props;
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
size_t nprops;
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
int capsCondition;
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
};
qemu_capabilities: Separate out device props fetching The code is generic enough to be reused. Move it into a separate function. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 12:39:43 +00:00
typedef int (*virQEMUCapsObjectTypePropsCB)(qemuMonitorPtr mon,
const char *type,
char ***props);
static virQEMUCapsObjectTypeProps virQEMUCapsDeviceProps[] = {
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-blk-pci", virQEMUCapsDevicePropsVirtioBlk,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioBlk),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-net-pci", virQEMUCapsDevicePropsVirtioNet,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioNet),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_VIRTIO_NET },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-scsi-pci", virQEMUCapsDevicePropsVirtioSCSI,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioSCSI),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_VIRTIO_SCSI },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-blk-ccw", virQEMUCapsDevicePropsVirtioBlk,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioBlk),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_VIRTIO_CCW },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-net-ccw", virQEMUCapsDevicePropsVirtioNet,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioNet),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_VIRTIO_NET },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-scsi-ccw", virQEMUCapsDevicePropsVirtioSCSI,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioSCSI),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_VIRTIO_SCSI },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-blk-s390", virQEMUCapsDevicePropsVirtioBlk,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioBlk),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_VIRTIO_S390 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-net-s390", virQEMUCapsDevicePropsVirtioNet,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioNet),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_VIRTIO_NET },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "vfio-pci", virQEMUCapsDevicePropsVfioPCI,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVfioPCI),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_VFIO_PCI },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "scsi-disk", virQEMUCapsDevicePropsSCSIDisk,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsSCSIDisk),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "ide-drive", virQEMUCapsDevicePropsIDEDrive,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsIDEDrive),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "PIIX4_PM", virQEMUCapsDevicePropsPiix4PM,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsPiix4PM),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "usb-redir", virQEMUCapsDevicePropsUSBRedir,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsUSBRedir),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_USB_REDIR },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "i440FX-pcihost", virQEMUCapsDevicePropsI440FXPCIHost,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsI440FXPCIHost),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "q35-pcihost", virQEMUCapsDevicePropsQ35PCIHost,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsQ35PCIHost),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "usb-storage", virQEMUCapsDevicePropsUSBStorage,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsUSBStorage),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_USB_STORAGE },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "kvm-pit", virQEMUCapsDevicePropsKVMPit,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsKVMPit),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "VGA", virQEMUCapsDevicePropsVGA,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVGA),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_VGA },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "vmware-svga", virQEMUCapsDevicePropsVmwareSvga,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVmwareSvga),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_VMWARE_SVGA },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "qxl", virQEMUCapsDevicePropsQxl,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsQxl),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_QXL },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-gpu-pci", virQEMUCapsDevicePropsVirtioGpu,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioGpu),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_VIRTIO_GPU },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-gpu-device", virQEMUCapsDevicePropsVirtioGpu,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioGpu),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_DEVICE_VIRTIO_GPU },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "ICH9-LPC", virQEMUCapsDevicePropsICH9,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsICH9),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-balloon-pci", virQEMUCapsDevicePropsVirtioBalloon,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioBalloon),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-balloon-ccw", virQEMUCapsDevicePropsVirtioBalloon,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioBalloon),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-balloon-device", virQEMUCapsDevicePropsVirtioBalloon,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioBalloon),
qemu: allow conditional device property probing Do not probe for devices that QEMU does not know when probing for device options.
2017-03-20 15:08:48 +00:00
-1 },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "nec-usb-xhci", virQEMUCapsDevicePropsUSBNECXHCI,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsUSBNECXHCI),
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:49:39 +00:00
QEMU_CAPS_NEC_USB_XHCI },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "intel-iommu", virQEMUCapsDevicePropsIntelIOMMU,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsIntelIOMMU),
qemu_capabilities: Fix the formatting with a space It was observed while adding new property that there should be a space before closing a curly brace in intel-iommu object property definition. Fixing it as a separate patch. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
2017-07-24 05:55:16 +00:00
QEMU_CAPS_DEVICE_INTEL_IOMMU },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "spapr-pci-host-bridge", virQEMUCapsDevicePropsSpaprPCIHostBridge,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsSpaprPCIHostBridge),
qemu: capabilitity: Introduce QEMU_CAPS_SPAPR_PCI_HOST_BRIDGE_NUMA_NODE The patch adds a capability for spapr-pci-host-bridge.numa_node. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-07-21 08:02:32 +00:00
QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE },
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
{ "virtio-gpu-ccw", virQEMUCapsDevicePropsVirtioGpu,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsVirtioGpu),
qemu: Introduce a new capability for virtio-gpu-ccw QEMU on S390 (since v2.11) can support virtio-gpu-ccw device. Let's introduce a new qemu capability for the device. Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2018-03-23 17:22:38 +00:00
QEMU_CAPS_DEVICE_VIRTIO_GPU_CCW },
qemu: introduce vfio-ccw capability Let us introduce the capability vfio-ccw for supporting the basic channel I/O passthrough, which have been introduced in QEMU 2.10. The current focus is to support dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device. Let us also introduce the capability QEMU_CAPS_CCW_CSSID_UNRESTRICTED for virtual-css-bridge. This capability is based on the cssid-unrestricted property which exists if QEMU no longer enforces cssid restrictions based on ccw device types. Vfio-ccw capability is dependent on the hidden virtual-css-bridge, so that we are able to probe for the cssid-unrestriced property to make sure the devices are visible to non-mcss-e enabled guests. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:12 +00:00
{ "virtual-css-bridge", virQEMUCapsObjectPropsVirtualCSSBridge,
ARRAY_CARDINALITY(virQEMUCapsObjectPropsVirtualCSSBridge),
QEMU_CAPS_CCW },
qemu: Add capability flag for setting the extended tseg size For getting the reply I queried the newest and oldest QEMU using test/qemucapsprobe. From the differences I only extracted the reply to the new QMP command and discarded the rest. For all the versions below the one which added support for the new option I used the output from the oldest QEMU release and for those that support it I used the output from the newest one. In order to make doubly sure the reply is where it is supposed to be (the replies files are very forgiving) I added the property to all the replies files, reran the tests again and fixed the order in replies files so that all the versions are reporting the new capability. Then removed that one property. After that I used test/qemucapsfixreplies to fix the reply IDs. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-10 21:27:57 +00:00
{ "mch", virQEMUCapsDevicePropsMCH,
ARRAY_CARDINALITY(virQEMUCapsDevicePropsMCH),
QEMU_CAPS_DEVICE_MCH },
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
};
qemu_capabilities: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD This capability tracks if memory-backend-file has discard-data attribute or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-20 08:25:49 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsMemoryBackendFile[] = {
{ "discard-data", QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD },
};
qemu: Add capability for the HPT maxpagesize feature Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-06-19 11:51:05 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsSPAPRMachine[] = {
{ "cap-hpt-max-page-size", QEMU_CAPS_MACHINE_PSERIES_CAP_HPT_MAX_PAGE_SIZE },
qemu: Add capability for the HTM pSeries feature Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-06-19 11:51:05 +00:00
{ "cap-htm", QEMU_CAPS_MACHINE_PSERIES_CAP_HTM },
qemu: Add capability for the HPT maxpagesize feature Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-06-19 11:51:05 +00:00
};
qemu_capabilities: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD This capability tracks if memory-backend-file has discard-data attribute or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-20 08:25:49 +00:00
static virQEMUCapsObjectTypeProps virQEMUCapsObjectProps[] = {
{ "memory-backend-file", virQEMUCapsObjectPropsMemoryBackendFile,
ARRAY_CARDINALITY(virQEMUCapsObjectPropsMemoryBackendFile),
QEMU_CAPS_OBJECT_MEMORY_FILE },
qemu: Add capability for the HPT maxpagesize feature Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-06-19 11:51:05 +00:00
{ "spapr-machine", virQEMUCapsObjectPropsSPAPRMachine,
ARRAY_CARDINALITY(virQEMUCapsObjectPropsSPAPRMachine),
-1 },
qemu_capabilities: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD This capability tracks if memory-backend-file has discard-data attribute or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-20 08:25:49 +00:00
};
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
static void
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsProcessStringFlags(virQEMUCapsPtr qemuCaps,
size_t nflags,
struct virQEMUCapsStringFlags *flags,
size_t nvalues,
char *const*values)
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
{
size_t i, j;
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < nflags; i++) {
qemu: Ignore subsequent attempts to probe device properties In some cases, we are probing multiple devices for the same property and setting the corresponding capability if it's found on any of the devices: when that happens, we can quit early after finding the first property and avoiding a bunch of string comparisons. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 12:43:26 +00:00
if (virQEMUCapsGet(qemuCaps, flags[i].flag))
continue;
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (j = 0; j < nvalues; j++) {
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
if (STREQ(values[j], flags[i].value)) {
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsSet(qemuCaps, flags[i].flag);
Refactor qemuCapsParseDeviceStr to work from data tables Currently the qemuCapsParseDeviceStr method has a bunch of open coded string searches/comparisons to detect devices and their properties. Soon this data will be obtained from QMP queries instead of -device help output. Maintaining the list of device and properties in two places is undesirable. Thus the existing qemuCapsParseDeviceStr() method needs to be refactored to separate the device types and properties from the actual search code. Thus the -device help output is now parsed to construct a list of device names, and device properties. These are then checked against a set of datatables to set the capability flags Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 17:04:24 +00:00
break;
}
}
}
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
int virQEMUCapsGetDefaultVersion(virCapsPtr caps,
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virFileCachePtr capsCache,
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
unsigned int *version)
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr qemucaps;
qemu: simplify use of virArchFromHost Reusing the result of virArchFromHost instead of calling it multiple times Signed-off-by: Tal Kain <tal.kain@ravellosystems.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-04-08 12:33:07 +00:00
virArch hostarch;
caps: Use DomainDataLookup to replace GuestDefault* This revealed that GuestDefaultEmulator was a bit buggy, capable of returning an emulator that didn't match the passed domain type. Fix up the test suite input to continue to pass.
2015-04-18 00:15:25 +00:00
virCapsDomainDataPtr capsdata;
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
if (*version > 0)
return 0;
qemu: simplify use of virArchFromHost Reusing the result of virArchFromHost instead of calling it multiple times Signed-off-by: Tal Kain <tal.kain@ravellosystems.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-04-08 12:33:07 +00:00
hostarch = virArchFromHost();
caps: Use DomainDataLookup to replace GuestDefault* This revealed that GuestDefaultEmulator was a bit buggy, capable of returning an emulator that didn't match the passed domain type. Fix up the test suite input to continue to pass.
2015-04-18 00:15:25 +00:00
if (!(capsdata = virCapabilitiesDomainDataLookup(caps,
VIR_DOMAIN_OSTYPE_HVM, hostarch, VIR_DOMAIN_VIRT_QEMU,
NULL, NULL))) {
Replace use of qemuReportError with virReportError Update the QEMU driver to use virReportError instead of the qemuReportError custom macro Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-07-18 15:22:03 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR,
Convert capabilities / domain_conf to use virArch Convert the host capabilities and domain config structs to use the virArch datatype. Update the parsers and all drivers to take account of datatype change Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-12-10 22:28:09 +00:00
_("Cannot find suitable emulator for %s"),
qemu: simplify use of virArchFromHost Reusing the result of virArchFromHost instead of calling it multiple times Signed-off-by: Tal Kain <tal.kain@ravellosystems.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2013-04-08 12:33:07 +00:00
virArchToString(hostarch));
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
return -1;
}
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
qemucaps = virQEMUCapsCacheLookup(capsCache, capsdata->emulator);
caps: Use DomainDataLookup to replace GuestDefault* This revealed that GuestDefaultEmulator was a bit buggy, capable of returning an emulator that didn't match the passed domain type. Fix up the test suite input to continue to pass.
2015-04-18 00:15:25 +00:00
VIR_FREE(capsdata);
if (!qemucaps)
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
return -1;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
*version = virQEMUCapsGetVersion(qemucaps);
Remove probing of flags when launching QEMU guests Remove all use of the existing APIs for querying QEMU capability flags. Instead obtain a qemuCapsPtr object from the global cache. This avoids the execution of 'qemu -help' (and related commands) when launching new guests. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 14:39:54 +00:00
virObjectUnref(qemucaps);
Move QEMU capabilities management into a separate file The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file * src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c
2010-12-16 15:07:07 +00:00
return 0;
}
qemu: Use helper functions for handling cmd line capabilities Three new functions (qemuCapsSet, qemuCapsClear, and qemuCapsGet) were introduced replacing direct bit operations.
2011-02-08 14:08:12 +00:00
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr
virQEMUCapsNew(void)
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr qemuCaps;
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
if (virQEMUCapsInitialize() < 0)
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
return NULL;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
if (!(qemuCaps = virObjectNew(virQEMUCapsClass)))
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
return NULL;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
if (!(qemuCaps->flags = virBitmapNew(QEMU_CAPS_LAST)))
Adapt to VIR_ALLOC and virAsprintf in src/qemu/*
2013-07-04 10:14:12 +00:00
goto error;
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
return qemuCaps;
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
error:
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virObjectUnref(qemuCaps);
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
return NULL;
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
}
qemu: Move qemuCaps CPU data copying into a separate function This introduces virQEMUCapsHostCPUDataCopy which will later be refactored a bit and called twice from virQEMUCapsNewCopy. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:40:31 +00:00
static int
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virQEMUCapsHostCPUDataCopy(virQEMUCapsHostCPUDataPtr dst,
virQEMUCapsHostCPUDataPtr src)
qemu: Move qemuCaps CPU data copying into a separate function This introduces virQEMUCapsHostCPUDataCopy which will later be refactored a bit and called twice from virQEMUCapsNewCopy. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:40:31 +00:00
{
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
if (src->info &&
!(dst->info = qemuMonitorCPUModelInfoCopy(src->info)))
qemu: Move qemuCaps CPU data copying into a separate function This introduces virQEMUCapsHostCPUDataCopy which will later be refactored a bit and called twice from virQEMUCapsNewCopy. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:40:31 +00:00
return -1;
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
if (src->reported &&
!(dst->reported = virCPUDefCopy(src->reported)))
qemu: Move qemuCaps CPU data copying into a separate function This introduces virQEMUCapsHostCPUDataCopy which will later be refactored a bit and called twice from virQEMUCapsNewCopy. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:40:31 +00:00
return -1;
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
if (src->migratable &&
!(dst->migratable = virCPUDefCopy(src->migratable)))
return -1;
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
if (src->full &&
!(dst->full = virCPUDefCopy(src->full)))
return -1;
qemu: Move qemuCaps CPU data copying into a separate function This introduces virQEMUCapsHostCPUDataCopy which will later be refactored a bit and called twice from virQEMUCapsNewCopy. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:40:31 +00:00
return 0;
}
qemu: Introduce virQEMUCapsHostCPUDataClear To keep freeing of host CPU data in one place. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:43:59 +00:00
static void
qemu: remove unnecessary virQEMUCapsFreeHostCPUModel After removing the host CPU model re-computation, this function is no longer necessary. This reverts commits: commit d0498881a04dddd772f9f63b03de80fb4c33d090 virQEMUCapsFreeHostCPUModel: Don't always free host cpuData commit 5276ec712a44b3680569a096e8fe56a925f0d495 testUpdateQEMUCaps: Don't leak host cpuData Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-09-08 22:40:30 +00:00
virQEMUCapsHostCPUDataClear(virQEMUCapsHostCPUDataPtr cpuData)
qemu: Introduce virQEMUCapsHostCPUDataClear To keep freeing of host CPU data in one place. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:43:59 +00:00
{
qemu: remove unnecessary virQEMUCapsFreeHostCPUModel After removing the host CPU model re-computation, this function is no longer necessary. This reverts commits: commit d0498881a04dddd772f9f63b03de80fb4c33d090 virQEMUCapsFreeHostCPUModel: Don't always free host cpuData commit 5276ec712a44b3680569a096e8fe56a925f0d495 testUpdateQEMUCaps: Don't leak host cpuData Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-09-08 22:40:30 +00:00
qemuMonitorCPUModelInfoFree(cpuData->info);
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virCPUDefFree(cpuData->reported);
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
virCPUDefFree(cpuData->migratable);
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
virCPUDefFree(cpuData->full);
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
memset(cpuData, 0, sizeof(*cpuData));
qemu: Introduce virQEMUCapsHostCPUDataClear To keep freeing of host CPU data in one place. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:43:59 +00:00
}
qemu: caps: Format SEV platform data into qemuCaps cache Since we're not saving the platform-specific data into a cache, we're not going to populate the structure, which in turn will cause a crash upon calling virNodeGetSEVInfo because of a NULL pointer dereference. Ultimately, we should start caching this data along with host-specific capabilities like NUMA and SELinux stuff into a separate cache, but for the time being, this is a semi-proper fix for a potential crash. Backtrace (requires libvirtd restart to load qemu caps from cache): #0 qemuGetSEVInfoToParams #1 qemuNodeGetSEVInfo #2 virNodeGetSEVInfo #3 remoteDispatchNodeGetSevInfo #4 remoteDispatchNodeGetSevInfoHelper #5 virNetServerProgramDispatchCall #6 virNetServerProgramDispatch #7 virNetServerProcessMsg #8 virNetServerHandleJob #9 virThreadPoolWorker #10 virThreadHelper https: //bugzilla.redhat.com/show_bug.cgi?id=1612009 Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2018-08-09 13:27:26 +00:00
static int
virQEMUCapsSEVInfoCopy(virSEVCapabilityPtr *dst,
virSEVCapabilityPtr src)
{
VIR_AUTOPTR(virSEVCapability) tmp = NULL;
if (VIR_ALLOC(tmp) < 0 ||
VIR_STRDUP(tmp->pdh, src->pdh) < 0 ||
VIR_STRDUP(tmp->cert_chain, src->cert_chain) < 0)
return -1;
tmp->cbitpos = src->cbitpos;
tmp->reduced_phys_bits = src->reduced_phys_bits;
VIR_STEAL_PTR(*dst, tmp);
return 0;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr qemuCaps)
Add API for copying instances of the qemuCapsPtr object To allow each VM instance to record additional capabilities without affecting other VMs, there needs to be a way to do a deep copy of the qemuCapsPtr object
2012-09-11 12:42:20 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr ret = virQEMUCapsNew();
Add API for copying instances of the qemuCapsPtr object To allow each VM instance to record additional capabilities without affecting other VMs, there needs to be a way to do a deep copy of the qemuCapsPtr object
2012-09-11 12:42:20 +00:00
size_t i;
if (!ret)
return NULL;
qemu: Copy QEMU caps elements in order of definition Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-04 14:45:53 +00:00
ret->usedQMP = qemuCaps->usedQMP;
qemu: Copy missing QEMU caps elements Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-04 14:48:40 +00:00
if (VIR_STRDUP(ret->binary, qemuCaps->binary) < 0)
goto error;
ret->ctime = qemuCaps->ctime;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virBitmapCopy(ret->flags, qemuCaps->flags);
Add API for copying instances of the qemuCapsPtr object To allow each VM instance to record additional capabilities without affecting other VMs, there needs to be a way to do a deep copy of the qemuCapsPtr object
2012-09-11 12:42:20 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
ret->version = qemuCaps->version;
ret->kvmVersion = qemuCaps->kvmVersion;
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
ret->microcodeVersion = qemuCaps->microcodeVersion;
qemu: include libvirt & QEMU versions in QEMU log files It is often helpful to know which version of libvirt and QEMU was present when a guest was first launched. Ensure this info is written into the QEMU log file for each guest.
2015-02-02 10:28:30 +00:00
if (VIR_STRDUP(ret->package, qemuCaps->package) < 0)
goto error;
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
if (VIR_STRDUP(ret->kernelVersion, qemuCaps->kernelVersion) < 0)
goto error;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
ret->arch = qemuCaps->arch;
Add API for copying instances of the qemuCapsPtr object To allow each VM instance to record additional capabilities without affecting other VMs, there needs to be a way to do a deep copy of the qemuCapsPtr object
2012-09-11 12:42:20 +00:00
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (qemuCaps->kvmCPUModels) {
ret->kvmCPUModels = virDomainCapsCPUModelsCopy(qemuCaps->kvmCPUModels);
if (!ret->kvmCPUModels)
goto error;
}
if (qemuCaps->tcgCPUModels) {
ret->tcgCPUModels = virDomainCapsCPUModelsCopy(qemuCaps->tcgCPUModels);
if (!ret->tcgCPUModels)
Adapt to VIR_STRDUP and VIR_STRNDUP in src/qemu/*
2013-05-20 09:23:13 +00:00
goto error;
Add API for copying instances of the qemuCapsPtr object To allow each VM instance to record additional capabilities without affecting other VMs, there needs to be a way to do a deep copy of the qemuCapsPtr object
2012-09-11 12:42:20 +00:00
}
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
if (virQEMUCapsHostCPUDataCopy(&ret->kvmCPU, &qemuCaps->kvmCPU) < 0 ||
virQEMUCapsHostCPUDataCopy(&ret->tcgCPU, &qemuCaps->tcgCPU) < 0)
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
goto error;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
if (VIR_ALLOC_N(ret->machineTypes, qemuCaps->nmachineTypes) < 0)
Adapt to VIR_ALLOC and virAsprintf in src/qemu/*
2013-07-04 10:14:12 +00:00
goto error;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
ret->nmachineTypes = qemuCaps->nmachineTypes;
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (VIR_STRDUP(ret->machineTypes[i].name, qemuCaps->machineTypes[i].name) < 0 ||
VIR_STRDUP(ret->machineTypes[i].alias, qemuCaps->machineTypes[i].alias) < 0)
Adapt to VIR_STRDUP and VIR_STRNDUP in src/qemu/*
2013-05-20 09:23:13 +00:00
goto error;
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
ret->machineTypes[i].maxCpus = qemuCaps->machineTypes[i].maxCpus;
qemu: capabilities: Extract availability of new cpu hotplug for machine types QEMU reports whether 'query-hotpluggable-cpus' is supported for a given machine type. Extract and cache the information using the capability cache. When copying the capabilities for a new start of qemu, mask out the presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type doesn't support hotpluggable cpus.
2016-07-29 07:45:19 +00:00
ret->machineTypes[i].hotplugCpus = qemuCaps->machineTypes[i].hotplugCpus;
qemu: record the QEMU default machine in capabilities We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 12:18:27 +00:00
ret->machineTypes[i].qemuDefault = qemuCaps->machineTypes[i].qemuDefault;
Add API for copying instances of the qemuCapsPtr object To allow each VM instance to record additional capabilities without affecting other VMs, there needs to be a way to do a deep copy of the qemuCapsPtr object
2012-09-11 12:42:20 +00:00
}
qemu: Copy missing QEMU caps elements Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-04 14:48:40 +00:00
if (VIR_ALLOC_N(ret->gicCapabilities, qemuCaps->ngicCapabilities) < 0)
goto error;
ret->ngicCapabilities = qemuCaps->ngicCapabilities;
for (i = 0; i < qemuCaps->ngicCapabilities; i++)
ret->gicCapabilities[i] = qemuCaps->gicCapabilities[i];
qemu: caps: Format SEV platform data into qemuCaps cache Since we're not saving the platform-specific data into a cache, we're not going to populate the structure, which in turn will cause a crash upon calling virNodeGetSEVInfo because of a NULL pointer dereference. Ultimately, we should start caching this data along with host-specific capabilities like NUMA and SELinux stuff into a separate cache, but for the time being, this is a semi-proper fix for a potential crash. Backtrace (requires libvirtd restart to load qemu caps from cache): #0 qemuGetSEVInfoToParams #1 qemuNodeGetSEVInfo #2 virNodeGetSEVInfo #3 remoteDispatchNodeGetSevInfo #4 remoteDispatchNodeGetSevInfoHelper #5 virNetServerProgramDispatchCall #6 virNetServerProgramDispatch #7 virNetServerProcessMsg #8 virNetServerHandleJob #9 virThreadPoolWorker #10 virThreadHelper https: //bugzilla.redhat.com/show_bug.cgi?id=1612009 Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2018-08-09 13:27:26 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_GUEST) &&
virQEMUCapsSEVInfoCopy(&ret->sevCapabilities,
qemuCaps->sevCapabilities) < 0)
goto error;
Add API for copying instances of the qemuCapsPtr object To allow each VM instance to record additional capabilities without affecting other VMs, there needs to be a way to do a deep copy of the qemuCapsPtr object
2012-09-11 12:42:20 +00:00
return ret;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
error:
Add API for copying instances of the qemuCapsPtr object To allow each VM instance to record additional capabilities without affecting other VMs, there needs to be a way to do a deep copy of the qemuCapsPtr object
2012-09-11 12:42:20 +00:00
virObjectUnref(ret);
return NULL;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
void virQEMUCapsDispose(void *obj)
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr qemuCaps = obj;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
size_t i;
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
VIR_FREE(qemuCaps->machineTypes[i].name);
VIR_FREE(qemuCaps->machineTypes[i].alias);
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
VIR_FREE(qemuCaps->machineTypes);
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virObjectUnref(qemuCaps->kvmCPUModels);
virObjectUnref(qemuCaps->tcgCPUModels);
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virBitmapFree(qemuCaps->flags);
Introduce a API for creating QEMU capabilities for a binary Introduce a qemuCapsNewForBinary() API which creates a new QEMU capabilities object, populated with data relating to a specific QEMU binary. The qemuCaps object is also given a timestamp, which makes it possible to detect when the cached capabilities for a binary are out of date Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-10 10:47:56 +00:00
qemu: include libvirt & QEMU versions in QEMU log files It is often helpful to know which version of libvirt and QEMU was present when a guest was first launched. Ensure this info is written into the QEMU log file for each guest.
2015-02-02 10:28:30 +00:00
VIR_FREE(qemuCaps->package);
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
VIR_FREE(qemuCaps->kernelVersion);
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
VIR_FREE(qemuCaps->binary);
qemu: Probe GIC capabilities QEMU introduced the query-gic-capabilities QMP command with commit 4468d4e0f383: use the command, if available, to probe available GIC capabilities. The information obtained is stored in a virQEMUCaps instance, and will be later used to fill in a virDomainCaps instance.
2016-03-08 17:24:18 +00:00
VIR_FREE(qemuCaps->gicCapabilities);
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
qemu: free SEV caps in virQEMUCapsDispose Commit 77f51ab5 started parsing an copying the SEV capabilities, but omitted the free call. Signed-off-by: Ján Tomko <jtomko@redhat.com>
2018-09-08 23:26:36 +00:00
virSEVCapabilitiesFree(qemuCaps->sevCapabilities);
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virQEMUCapsHostCPUDataClear(&qemuCaps->kvmCPU);
virQEMUCapsHostCPUDataClear(&qemuCaps->tcgCPU);
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
}
qemu: Use helper functions for handling cmd line capabilities Three new functions (qemuCapsSet, qemuCapsClear, and qemuCapsGet) were introduced replacing direct bit operations.
2011-02-08 14:08:12 +00:00
void
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsSet(virQEMUCapsPtr qemuCaps,
qemu: enum cleanups in "src/qemu/*" As we are doing with the enum structures, a cleanup in "src/qemu/" directory was done now. All the enums that were defined in the header files were converted to typedefs in this directory. This patch includes all the adjustments to remove conflicts when you do this kind of change. "Enum-to-typedef"'s conversions were made in "src/qemu/qemu_{capabilities, domain, migration, hotplug}.h". Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
2014-06-15 16:32:56 +00:00
virQEMUCapsFlags flag)
qemu: Use helper functions for handling cmd line capabilities Three new functions (qemuCapsSet, qemuCapsClear, and qemuCapsGet) were introduced replacing direct bit operations.
2011-02-08 14:08:12 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
ignore_value(virBitmapSetBit(qemuCaps->flags, flag));
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
}
void
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsSetList(virQEMUCapsPtr qemuCaps, ...)
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
{
va_list list;
int flag;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
va_start(list, qemuCaps);
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
while ((flag = va_arg(list, int)) < QEMU_CAPS_LAST)
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
ignore_value(virBitmapSetBit(qemuCaps->flags, flag));
qemu: Switch over command line capabilities to virBitmap This is done for two reasons: - we are getting very close to 64 flags which is the maximum we can use with unsigned long long - by using LL constants in enum we already violates C99 constraint that enum values have to fit into int
2011-02-08 14:22:39 +00:00
va_end(list);
qemu: Use helper functions for handling cmd line capabilities Three new functions (qemuCapsSet, qemuCapsClear, and qemuCapsGet) were introduced replacing direct bit operations.
2011-02-08 14:08:12 +00:00
}
void
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsClear(virQEMUCapsPtr qemuCaps,
qemu: enum cleanups in "src/qemu/*" As we are doing with the enum structures, a cleanup in "src/qemu/" directory was done now. All the enums that were defined in the header files were converted to typedefs in this directory. This patch includes all the adjustments to remove conflicts when you do this kind of change. "Enum-to-typedef"'s conversions were made in "src/qemu/qemu_{capabilities, domain, migration, hotplug}.h". Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
2014-06-15 16:32:56 +00:00
virQEMUCapsFlags flag)
qemu: Use helper functions for handling cmd line capabilities Three new functions (qemuCapsSet, qemuCapsClear, and qemuCapsGet) were introduced replacing direct bit operations.
2011-02-08 14:08:12 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
ignore_value(virBitmapClearBit(qemuCaps->flags, flag));
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
char *virQEMUCapsFlagsString(virQEMUCapsPtr qemuCaps)
Turn QEMU capabilities object into a full virObjectPtr The current qemu capabilities are stored in a virBitmapPtr object, whose type is exposed to callers. We want to store more data besides just the flags, so we need to move to a struct type. This object will also need to be reference counted, since we'll be maintaining a cache of data per binary. This change introduces a 'qemuCapsPtr' virObject class. Most of the change is just renaming types and variables in all the callers Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-20 16:44:14 +00:00
{
util: Don't output too many zeros from virBitmapToString Truncate the output so that it is only as big as is needed to fit all the bits, not all the units from the map. This will be needed in the future in order to properly format bitmaps for kernel's sysfs files. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-08-23 07:09:17 +00:00
return virBitmapToString(qemuCaps->flags, true, false);
qemu: Use helper functions for handling cmd line capabilities Three new functions (qemuCapsSet, qemuCapsClear, and qemuCapsGet) were introduced replacing direct bit operations.
2011-02-08 14:08:12 +00:00
}
bool
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsGet(virQEMUCapsPtr qemuCaps,
qemu: enum cleanups in "src/qemu/*" As we are doing with the enum structures, a cleanup in "src/qemu/" directory was done now. All the enums that were defined in the header files were converted to typedefs in this directory. This patch includes all the adjustments to remove conflicts when you do this kind of change. "Enum-to-typedef"'s conversions were made in "src/qemu/qemu_{capabilities, domain, migration, hotplug}.h". Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
2014-06-15 16:32:56 +00:00
virQEMUCapsFlags flag)
qemu: Use helper functions for handling cmd line capabilities Three new functions (qemuCapsSet, qemuCapsClear, and qemuCapsGet) were introduced replacing direct bit operations.
2011-02-08 14:08:12 +00:00
{
Introduce virBitmapIsBitSet A helper that never returns an error and treats bits out of bitmap range as false. Use it everywhere we use ignore_value on virBitmapGetBit, or loop over the bitmap size.
2015-03-11 15:41:57 +00:00
return qemuCaps && virBitmapIsBitSet(qemuCaps->flags, flag);
qemu: Use helper functions for handling cmd line capabilities Three new functions (qemuCapsSet, qemuCapsClear, and qemuCapsGet) were introduced replacing direct bit operations.
2011-02-08 14:08:12 +00:00
}
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
bool virQEMUCapsHasPCIMultiBus(virQEMUCapsPtr qemuCaps,
virQEMUCapsHasPCIMultiBus: Fix @def type This function only queries domain @def. It doesn't change it. Therefore it should take const pointer. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-11-15 14:17:39 +00:00
const virDomainDef *def)
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
{
qemu: Drop QEMU_CAPS_PCI_MULTIBUS Due to the extra architecture-specific logic, it's already necessary for users to call virQEMUCapsHasPCIMultiBus(), so the capability itself is just a pointless distraction.
2017-03-02 14:40:29 +00:00
/* x86_64 and i686 support PCI-multibus on all machine types
* since forever */
virQEMUCapsHasPCIMultiBus: use def->os.arch We do not fill out qemuCaps->arch when parsing status XML. Use def->os.arch like we do for PPC. This fixes hotplug after daemon restart for domains that use a user alias for the implicit pci-root on x86. https://bugzilla.redhat.com/show_bug.cgi?id=1518148
2017-11-29 13:51:22 +00:00
if (ARCH_IS_X86(def->os.arch))
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
return true;
if (def->os.arch == VIR_ARCH_PPC ||
Cpu: Add support for Power LE Architecture. This adds support for PowerPC Little Endian architecture., and allows libvirt to spawn VMs based on 'ppc64le' architecture. Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com> Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2014-11-04 17:21:26 +00:00
ARCH_IS_PPC64(def->os.arch)) {
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
/*
* Usage of pci.0 naming:
*
* ref405ep: no pci
* taihu: no pci
qemu: Drop redundant version checks We require QEMU 1.5.0 these days, so checking for versions older than that is pointless. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-09-12 12:41:25 +00:00
* bamboo: 1.1.0 (<= 1.5.0, so basically forever)
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
* mac99: 2.0.0
* g3beige: 2.0.0
qemu: Drop redundant version checks We require QEMU 1.5.0 these days, so checking for versions older than that is pointless. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-09-12 12:41:25 +00:00
* prep: 1.4.0 (<= 1.5.0, so basically forever)
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
* pseries: 2.0.0
* mpc8544ds: forever
* virtex-m507: no pci
* ppce500: 1.6.0
*/
virQEMUCapsHasPCIMultiBus: assume true if we have no version information In status XML, we do not store the QEMU version information, we only format all the capabilities. We dropped QEMU_CAPS_PCI_MULTIBUS in commit 5b783379 which was released in libvirt 3.2.0. Therefore the only way of telling if the already running domain at the time of daemon restart has been started with a QEMU that does use 'pci.0' or not on PPC is to look at the pci-root controller's alias. This is not an option if the domain has a user-specified alias for the pci-root. Instead of reintroducing the capability, assume 'pci.0' when we have no version information. That way the only left broken use case would be the combination of user aliases and very old QEMU. Partially reverts commit 3a37af1e4. https://bugzilla.redhat.com/show_bug.cgi?id=1518148
2017-11-29 14:05:23 +00:00
/* We do not store the qemu version in domain status XML.
* Hope the user is using a QEMU new enough to use 'pci.0',
* otherwise the results of this function will be wrong
* for domains already running at the time of daemon
* restart */
if (qemuCaps->version == 0)
return true;
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
if (qemuCaps->version >= 2000000)
return true;
if (qemuCaps->version >= 1006000 &&
STREQ(def->os.machine, "ppce500"))
return true;
qemu: Drop redundant version checks We require QEMU 1.5.0 these days, so checking for versions older than that is pointless. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-09-12 12:41:25 +00:00
if (STREQ(def->os.machine, "bamboo") ||
STREQ(def->os.machine, "mpc8544ds") ||
STREQ(def->os.machine, "prep")) {
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
return true;
qemu: Drop redundant version checks We require QEMU 1.5.0 these days, so checking for versions older than that is pointless. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-09-12 12:41:25 +00:00
}
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
return false;
}
qemu: Rename qemuDomain*IsVirt() to qemuDomain*IsARMVirt() They're ARM specific. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-08-22 09:15:20 +00:00
/* If ARM 'virt' supports PCI, it supports multibus.
qemu: Add architecture checks to qemuDomainMachineIsVirt() Remove all external architecture checks that have been made redundant by this change.
2016-06-22 16:55:37 +00:00
* No extra conditions here for simplicity.
*/
qemu: Rename qemuDomain*IsVirt() to qemuDomain*IsARMVirt() They're ARM specific. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-08-22 09:15:20 +00:00
if (qemuDomainIsARMVirt(def))
qemu: Add architecture checks to qemuDomainMachineIsVirt() Remove all external architecture checks that have been made redundant by this change.
2016-06-22 16:55:37 +00:00
return true;
qemu: Add PCI-Express root to ARM virt machine Here we assume that if qemu supports generic PCI host controller, it is a part of virt machine and can be used for adding PCI devices. In qemu this is actually a PCIe bus, so we also declare multibus capability so that 0'th bus is specified to qemu correctly as 'pcie.0' Signed-off-by: Pavel Fedin <p.fedin@samsung.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-07-17 11:27:45 +00:00
Fix pci bus naming for PPC Recent discussions around naming of 'pci' vs 'pci.0' for PPC made me go back and look at the PPC emulator in every historical version of QEMU since 1.0. The results were worse than I imagined. This patch adds the logic required to make libvirt work with PPC correctly with naming variations across all versions & machine types. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-04-23 15:35:37 +00:00
return false;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
const char *virQEMUCapsGetBinary(virQEMUCapsPtr qemuCaps)
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
return qemuCaps->binary;
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
}
qemuxml2argvtest: Properly initialize qemuCaps->arch qemuCaps->arch should match the guest architecture from domain XML. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 10:26:41 +00:00
void
virQEMUCapsSetArch(virQEMUCapsPtr qemuCaps,
virArch arch)
{
qemuCaps->arch = arch;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virArch virQEMUCapsGetArch(virQEMUCapsPtr qemuCaps)
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
return qemuCaps->arch;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
unsigned int virQEMUCapsGetVersion(virQEMUCapsPtr qemuCaps)
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
return qemuCaps->version;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
unsigned int virQEMUCapsGetKVMVersion(virQEMUCapsPtr qemuCaps)
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
return qemuCaps->kvmVersion;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
}
qemu: include libvirt & QEMU versions in QEMU log files It is often helpful to know which version of libvirt and QEMU was present when a guest was first launched. Ensure this info is written into the QEMU log file for each guest.
2015-02-02 10:28:30 +00:00
const char *virQEMUCapsGetPackage(virQEMUCapsPtr qemuCaps)
{
return qemuCaps->package;
}
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
int
virQEMUCapsAddCPUDefinitions(virQEMUCapsPtr qemuCaps,
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virDomainVirtType type,
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
const char **name,
qemu: Add support for unavailable-features QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the CPU model can be used without modifications. We can use unavailable-features for providing CPU model usability info in domain capabilities XML: <domainCapabilities> ... <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'> <model fallback='allow'>Skylake-Client</model> ... </mode> <mode name='custom' supported='yes'> <model usable='yes'>qemu64</model> <model usable='yes'>qemu32</model> <model usable='no'>phenom</model> <model usable='yes'>pentium3</model> <model usable='yes'>pentium2</model> <model usable='yes'>pentium</model> <model usable='yes'>n270</model> <model usable='yes'>kvm64</model> <model usable='yes'>kvm32</model> <model usable='yes'>coreduo</model> <model usable='yes'>core2duo</model> <model usable='no'>athlon</model> <model usable='yes'>Westmere</model> <model usable='yes'>Skylake-Client</model> ... </mode> </cpu> ... </domainCapabilities> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 11:08:12 +00:00
size_t count,
virDomainCapsCPUUsable usable)
Remove probing of CPU models when launching QEMU guests When launching a QEMU guest the binary is probed to discover the list of supported CPU names. Remove this probing with a simple lookup of CPU models in the qemuCapsPtr object. This avoids another invocation of the QEMU binary during the startup path. As a nice benefit we can now remove all the nasty hacks from the test suite which were done to avoid having to exec QEMU on the test system. The building of the -cpu command line can just rely on data we pre-populate in qemuCapsPtr. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 15:28:55 +00:00
{
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
size_t i;
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virDomainCapsCPUModelsPtr cpus = NULL;
Adapt to VIR_STRDUP and VIR_STRNDUP in src/qemu/*
2013-05-20 09:23:13 +00:00
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (type == VIR_DOMAIN_VIRT_KVM && qemuCaps->kvmCPUModels)
cpus = qemuCaps->kvmCPUModels;
else if (type == VIR_DOMAIN_VIRT_QEMU && qemuCaps->tcgCPUModels)
cpus = qemuCaps->tcgCPUModels;
if (!cpus) {
if (!(cpus = virDomainCapsCPUModelsNew(count)))
return -1;
if (type == VIR_DOMAIN_VIRT_KVM)
qemuCaps->kvmCPUModels = cpus;
else
qemuCaps->tcgCPUModels = cpus;
}
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
for (i = 0; i < count; i++) {
conf: Add usability blockers to virDomainCapsCPUModel When a hypervisor marks a CPU model as unusable on the current host, it may also give us a list of features which prevent the model from being usable. Storing this list in virDomainCapsCPUModel will help the CPU driver with creating a host-model CPU configuration. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-19 16:35:08 +00:00
if (virDomainCapsCPUModelsAdd(cpus, name[i], -1, usable, NULL) < 0)
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
return -1;
Remove probing of CPU models when launching QEMU guests When launching a QEMU guest the binary is probed to discover the list of supported CPU names. Remove this probing with a simple lookup of CPU models in the qemuCapsPtr object. This avoids another invocation of the QEMU binary during the startup path. As a nice benefit we can now remove all the nasty hacks from the test suite which were done to avoid having to exec QEMU on the test system. The building of the -cpu command line can just rely on data we pre-populate in qemuCapsPtr. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 15:28:55 +00:00
}
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
Remove probing of CPU models when launching QEMU guests When launching a QEMU guest the binary is probed to discover the list of supported CPU names. Remove this probing with a simple lookup of CPU models in the qemuCapsPtr object. This avoids another invocation of the QEMU binary during the startup path. As a nice benefit we can now remove all the nasty hacks from the test suite which were done to avoid having to exec QEMU on the test system. The building of the -cpu command line can just rely on data we pre-populate in qemuCapsPtr. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 15:28:55 +00:00
return 0;
}
cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs All APIs which expect a list of CPU models supported by hypervisors were switched from char **models and int models to just accept a pointer to virDomainCapsCPUModels object stored in domain capabilities. This avoids the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated list of model names and also allows the various cpu driver APIs to access additional details (such as its usability) about each CPU model. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-22 13:51:33 +00:00
virDomainCapsCPUModelsPtr
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
virQEMUCapsGetCPUDefinitions(virQEMUCapsPtr qemuCaps,
cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs All APIs which expect a list of CPU models supported by hypervisors were switched from char **models and int models to just accept a pointer to virDomainCapsCPUModels object stored in domain capabilities. This avoids the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated list of model names and also allows the various cpu driver APIs to access additional details (such as its usability) about each CPU model. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-22 13:51:33 +00:00
virDomainVirtType type)
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
{
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (type == VIR_DOMAIN_VIRT_KVM)
cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs All APIs which expect a list of CPU models supported by hypervisors were switched from char **models and int models to just accept a pointer to virDomainCapsCPUModels object stored in domain capabilities. This avoids the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated list of model names and also allows the various cpu driver APIs to access additional details (such as its usability) about each CPU model. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-22 13:51:33 +00:00
return qemuCaps->kvmCPUModels;
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
else
cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs All APIs which expect a list of CPU models supported by hypervisors were switched from char **models and int models to just accept a pointer to virDomainCapsCPUModels object stored in domain capabilities. This avoids the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated list of model names and also allows the various cpu driver APIs to access additional details (such as its usability) about each CPU model. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-22 13:51:33 +00:00
return qemuCaps->tcgCPUModels;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
}
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
static virQEMUCapsHostCPUDataPtr
virQEMUCapsGetHostCPUData(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
if (type == VIR_DOMAIN_VIRT_KVM)
return &qemuCaps->kvmCPU;
else
return &qemuCaps->tcgCPU;
}
qemu: Introduce virQEMUCapsGetHostModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-22 10:34:07 +00:00
virCPUDefPtr
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
virQEMUCapsGetHostModel(virQEMUCapsPtr qemuCaps,
qemu: Prepare qemuCaps for multiple host CPU defs Soon we will need to store multiple host CPU definitions in virQEMUCapsHostCPUData and qemuCaps users will want to request the one they need. This patch introduces virQEMUCapsHostCPUType enum which will be used for specifying the requested CPU definition. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 09:14:30 +00:00
virDomainVirtType type,
virQEMUCapsHostCPUType cpuType)
qemu: Introduce virQEMUCapsGetHostModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-22 10:34:07 +00:00
{
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type);
qemu: Prepare qemuCaps for multiple host CPU defs Soon we will need to store multiple host CPU definitions in virQEMUCapsHostCPUData and qemuCaps users will want to request the one they need. This patch introduces virQEMUCapsHostCPUType enum which will be used for specifying the requested CPU definition. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 09:14:30 +00:00
switch (cpuType) {
case VIR_QEMU_CAPS_HOST_CPU_REPORTED:
return cpuData->reported;
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
case VIR_QEMU_CAPS_HOST_CPU_MIGRATABLE:
return cpuData->migratable;
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
case VIR_QEMU_CAPS_HOST_CPU_FULL:
/* 'full' is non-NULL only if we have data from both QEMU and
* virCPUGetHost */
return cpuData->full ? cpuData->full : cpuData->reported;
qemu: Prepare qemuCaps for multiple host CPU defs Soon we will need to store multiple host CPU definitions in virQEMUCapsHostCPUData and qemuCaps users will want to request the one they need. This patch introduces virQEMUCapsHostCPUType enum which will be used for specifying the requested CPU definition. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 09:14:30 +00:00
}
return NULL;
qemu: Introduce virQEMUCapsGetHostModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-22 10:34:07 +00:00
}
qemu: Introduce virQEMUCapsSetHostModel A simple helper as a complement to virQEMUCapsGetHostModel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:03:38 +00:00
static void
virQEMUCapsSetHostModel(virQEMUCapsPtr qemuCaps,
virDomainVirtType type,
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
virCPUDefPtr reported,
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
virCPUDefPtr migratable,
virCPUDefPtr full)
qemu: Introduce virQEMUCapsSetHostModel A simple helper as a complement to virQEMUCapsGetHostModel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:03:38 +00:00
{
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type);
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
cpuData->reported = reported;
cpuData->migratable = migratable;
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
cpuData->full = full;
qemu: Introduce virQEMUCapsSetHostModel A simple helper as a complement to virQEMUCapsGetHostModel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 15:03:38 +00:00
}
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
bool
virQEMUCapsIsCPUModeSupported(virQEMUCapsPtr qemuCaps,
virCapsPtr caps,
virDomainVirtType type,
virCPUMode mode)
{
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virDomainCapsCPUModelsPtr cpus;
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
switch (mode) {
case VIR_CPU_MODE_HOST_PASSTHROUGH:
return type == VIR_DOMAIN_VIRT_KVM &&
virQEMUCapsGuestIsNative(caps->host.arch, qemuCaps->arch);
case VIR_CPU_MODE_HOST_MODEL:
qemu: Prepare qemuCaps for multiple host CPU defs Soon we will need to store multiple host CPU definitions in virQEMUCapsHostCPUData and qemuCaps users will want to request the one they need. This patch introduces virQEMUCapsHostCPUType enum which will be used for specifying the requested CPU definition. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 09:14:30 +00:00
return !!virQEMUCapsGetHostModel(qemuCaps, type,
VIR_QEMU_CAPS_HOST_CPU_REPORTED);
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
case VIR_CPU_MODE_CUSTOM:
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (type == VIR_DOMAIN_VIRT_KVM)
cpus = qemuCaps->kvmCPUModels;
else
cpus = qemuCaps->tcgCPUModels;
return cpus && cpus->nmodels > 0;
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
case VIR_CPU_MODE_LAST:
break;
}
return false;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
int virQEMUCapsGetMachineTypesCaps(virQEMUCapsPtr qemuCaps,
size_t *nmachines,
virCapsGuestMachinePtr **machines)
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
{
size_t i;
*machines = NULL;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
*nmachines = qemuCaps->nmachineTypes;
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
Fix Memory Leak in virQEMUCapsInitGuestFromBinary() While running qemucaps2xmltest, it was found that valgrind pointed out the following memory leaks: ==29896== 0 bytes in 1 blocks are definitely lost in loss record 1 of 65 ==29896== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==29896== by 0x4C6B45E: virAllocN (viralloc.c:191) ==29896== by 0x4232A9: virQEMUCapsGetMachineTypesCaps (qemu_capabilities.c:1999) ==29896== by 0x4234E7: virQEMUCapsInitGuestFromBinary (qemu_capabilities.c:789) ==29896== by 0x41F10B: testQemuCapsXML (qemucaps2xmltest.c:118) ==29896== by 0x41FFD1: virtTestRun (testutils.c:201) ==29896== by 0x41EE7A: mymain (qemucaps2xmltest.c:203) ==29896== by 0x42074D: virtTestMain (testutils.c:789) ==29896== by 0x3E6CE1ED1C: (below main) (libc-start.c:226) ==29896== ==29896== 0 bytes in 1 blocks are definitely lost in loss record 2 of 65 ==29896== at 0x4A0577B: calloc (vg_replace_malloc.c:593) ==29896== by 0x4C6B45E: virAllocN (viralloc.c:191) ==29896== by 0x4232A9: virQEMUCapsGetMachineTypesCaps (qemu_capabilities.c:1999) ==29896== by 0x4234E7: virQEMUCapsInitGuestFromBinary (qemu_capabilities.c:789) ==29896== by 0x41F10B: testQemuCapsXML (qemucaps2xmltest.c:118) ==29896== by 0x41FFD1: virtTestRun (testutils.c:201) ==29896== by 0x41EEA3: mymain (qemucaps2xmltest.c:204) ==29896== by 0x42074D: virtTestMain (testutils.c:789) ==29896== by 0x3E6CE1ED1C: (below main) (libc-start.c:226) Signed-off-by: Eric Blake <eblake@redhat.com>
2014-03-27 11:38:56 +00:00
if (*nmachines &&
VIR_ALLOC_N(*machines, qemuCaps->nmachineTypes) < 0)
goto error;
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
virCapsGuestMachinePtr mach;
if (VIR_ALLOC(mach) < 0)
Adapt to VIR_STRDUP and VIR_STRNDUP in src/qemu/*
2013-05-20 09:23:13 +00:00
goto error;
qemu_capabilities: Resolve Coverity RESOURCE_LEAK Coverity determined that on error path that 'mach' wouldn't be free'd Since virCapabilitiesFreeGuestMachine() isn't globally available, we'll insert first and then if the VIR_STRDUP's fail they it will eventually cause the 'mach' to be freed in the error path
2014-08-27 18:57:08 +00:00
(*machines)[i] = mach;
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (qemuCaps->machineTypes[i].alias) {
if (VIR_STRDUP(mach->name, qemuCaps->machineTypes[i].alias) < 0 ||
VIR_STRDUP(mach->canonical, qemuCaps->machineTypes[i].name) < 0)
Adapt to VIR_STRDUP and VIR_STRNDUP in src/qemu/*
2013-05-20 09:23:13 +00:00
goto error;
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
} else {
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (VIR_STRDUP(mach->name, qemuCaps->machineTypes[i].name) < 0)
Adapt to VIR_STRDUP and VIR_STRNDUP in src/qemu/*
2013-05-20 09:23:13 +00:00
goto error;
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
}
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
mach->maxCpus = qemuCaps->machineTypes[i].maxCpus;
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
}
qemu: Report all supported machine types in capabilities Some machine types are only reported as canonical names for other machine types, which make it a bit harder to find what machine types are supported by a specific QEMU binary. Ideally, one would just use /capabilities/guest/arch[@name='...']/machine/text() XPath to get a list of all supported machine types, but it doesn't work right now. For example, we report <machine canonical='pc-i440fx-2.3' maxCpus='255'>pc</machine> in guest capabilities, but the corresponding <machine maxCpus='255'>pc-i440fx-2.3</machine> is missing. This is a result of QMP probing. With "-machine ?" parsing QEMU sends us two lines: pc Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.3) pc-i440fx-2.3 Standard PC (i440FX + PIIX, 1996) (default) while query-machines QMP command reports both in the same entry: {"name": "pc-i440fx-2.3", "is-default": true, "cpu-max": 255, "alias": "pc"} Let's make sure we always report separate <machine/> for both the canonical name and its alias and using the canonical name as the default machine type (i.e., inserting it before its alias) in case is-default is true. https://bugzilla.redhat.com/show_bug.cgi?id=1229666 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2015-06-12 12:36:51 +00:00
/* Make sure all canonical machine types also have their own entry so that
* /capabilities/guest/arch[@name='...']/machine/text() XPath selects all
* supported machine types.
*/
i = 0;
while (i < *nmachines) {
size_t j;
bool found = false;
virCapsGuestMachinePtr machine = (*machines)[i];
if (!machine->canonical) {
i++;
continue;
}
for (j = 0; j < *nmachines; j++) {
if (STREQ(machine->canonical, (*machines)[j]->name)) {
found = true;
break;
}
}
if (!found) {
virCapsGuestMachinePtr mach;
if (VIR_ALLOC(mach) < 0)
goto error;
if (VIR_INSERT_ELEMENT_COPY(*machines, i, *nmachines, mach) < 0) {
VIR_FREE(mach);
goto error;
}
if (VIR_STRDUP(mach->name, machine->canonical) < 0)
goto error;
mach->maxCpus = machine->maxCpus;
i++;
}
i++;
}
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
return 0;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
error:
Switch over to use cache for building QEMU capabilities When building up a virCapsPtr instance, the QEMU driver was copying the list of machine types across from the previous virCapsPtr instance, if the QEMU binary had not changed. Replace this ad-hoc caching of data with use of the new qemuCapsCache global cache. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 13:37:05 +00:00
virCapabilitiesFreeMachines(*machines, *nmachines);
*nmachines = 0;
*machines = NULL;
return -1;
}
qemu: capabilities: Tolerate missing @qemuCaps in virQEMUCapsGetCanonicalMachine If qemuCaps are not present, just return the original machine type name. This will help in situations when qemuCaps is not available in the post parse callback.
2017-08-16 13:37:18 +00:00
/**
* virQEMUCapsGetCanonicalMachine:
* @qemuCaps: qemu capabilities object
* @name: machine name
*
* Resolves aliased machine names to the actual machine name. If qemuCaps isn't
* present @name is returned.
*/
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
const char *virQEMUCapsGetCanonicalMachine(virQEMUCapsPtr qemuCaps,
const char *name)
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
{
size_t i;
qemu: capabilities: Tolerate missing @qemuCaps in virQEMUCapsGetCanonicalMachine If qemuCaps are not present, just return the original machine type name. This will help in situations when qemuCaps is not available in the post parse callback.
2017-08-16 13:37:18 +00:00
if (!name || !qemuCaps)
return name;
qemu: use default machine type if missing it in qemu command line BZ:https://bugzilla.redhat.com/show_bug.cgi?id=871273 when using virsh qemu-attach to attach an existing qemu process, if it misses the -M option in qemu command line, libvirtd crashed because the NULL value of def->os.machine in later use. Example: /usr/libexec/qemu-kvm -name foo \ -cdrom /var/lib/libvirt/images/boot.img \ -monitor unix:/tmp/demo,server,nowait \ error: End of file while reading data: Input/output error error: Failed to reconnect to the hypervisor This patch tries to set default machine type if the value of def->os.machine is still NULL after qemu command line parsing.
2012-11-01 11:43:03 +00:00
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (!qemuCaps->machineTypes[i].alias)
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
continue;
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (STREQ(qemuCaps->machineTypes[i].alias, name))
return qemuCaps->machineTypes[i].name;
Add ability to store other metadata in the qemu capabilities object Add struct fields and APIs to allow the qemu capabilities object to store version, arch, machines & cpu names, etc Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 10:11:28 +00:00
}
return name;
}
Introduce a API for creating QEMU capabilities for a binary Introduce a qemuCapsNewForBinary() API which creates a new QEMU capabilities object, populated with data relating to a specific QEMU binary. The qemuCaps object is also given a timestamp, which makes it possible to detect when the cached capabilities for a binary are out of date Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-10 10:47:56 +00:00
qemu: fix default machine for argv -> xml convertor Historically the argv -> xml convertor wanted the same default machine as we'd set when parsing xml. The latter has now changed, however, to use a default defined by libvirt. The former needs fixing to again honour the default QEMU machine. This exposed a bug in handling for the aarch64 target, as QEMU does not define any default machine. Thus we should not having been accepting argv without a -machine provided. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-13 11:42:01 +00:00
const char *
virQEMUCapsGetDefaultMachine(virQEMUCapsPtr qemuCaps)
{
size_t i;
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
if (qemuCaps->machineTypes[i].qemuDefault)
return qemuCaps->machineTypes[i].name;
}
return NULL;
}
Introduce a API for creating QEMU capabilities for a binary Introduce a qemuCapsNewForBinary() API which creates a new QEMU capabilities object, populated with data relating to a specific QEMU binary. The qemuCaps object is also given a timestamp, which makes it possible to detect when the cached capabilities for a binary are out of date Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-10 10:47:56 +00:00
qemu: Implement CPUs check against machine type's cpu-max Implement check whether (maximum) vCPUs doesn't exceed machine type's cpu-max settings. On older versions of QEMU the check is disabled. Signed-off-by: Michal Novotny <minovotn@redhat.com>
2013-06-26 15:46:35 +00:00
int virQEMUCapsGetMachineMaxCpus(virQEMUCapsPtr qemuCaps,
const char *name)
{
size_t i;
if (!name)
return 0;
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (!qemuCaps->machineTypes[i].maxCpus)
qemu: Implement CPUs check against machine type's cpu-max Implement check whether (maximum) vCPUs doesn't exceed machine type's cpu-max settings. On older versions of QEMU the check is disabled. Signed-off-by: Michal Novotny <minovotn@redhat.com>
2013-06-26 15:46:35 +00:00
continue;
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (STREQ(qemuCaps->machineTypes[i].name, name))
return qemuCaps->machineTypes[i].maxCpus;
qemu: Implement CPUs check against machine type's cpu-max Implement check whether (maximum) vCPUs doesn't exceed machine type's cpu-max settings. On older versions of QEMU the check is disabled. Signed-off-by: Michal Novotny <minovotn@redhat.com>
2013-06-26 15:46:35 +00:00
}
return 0;
}
qemu: capabilities: Extract availability of new cpu hotplug for machine types QEMU reports whether 'query-hotpluggable-cpus' is supported for a given machine type. Extract and cache the information using the capability cache. When copying the capabilities for a new start of qemu, mask out the presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type doesn't support hotpluggable cpus.
2016-07-29 07:45:19 +00:00
bool virQEMUCapsGetMachineHotplugCpus(virQEMUCapsPtr qemuCaps,
const char *name)
{
size_t i;
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
if (STREQ_NULLABLE(qemuCaps->machineTypes[i].name, name))
return qemuCaps->machineTypes[i].hotplugCpus;
}
return false;
}
qemu: Add virQEMUCapsSetGICCapabilities() For use in the test suite.
2016-05-10 08:50:34 +00:00
/**
* virQEMUCapsSetGICCapabilities:
* @qemuCaps: QEMU capabilities
* @capabilities: GIC capabilities
* @ncapabilities: number of GIC capabilities
*
* Set the GIC capabilities for @qemuCaps.
*
* The ownership of @capabilities is taken away from the caller, ie. this
* function will not make a copy of @capabilities, so releasing that memory
* after it's been called is a bug.
*/
void
virQEMUCapsSetGICCapabilities(virQEMUCapsPtr qemuCaps,
virGICCapability *capabilities,
size_t ncapabilities)
{
VIR_FREE(qemuCaps->gicCapabilities);
qemuCaps->gicCapabilities = capabilities;
qemuCaps->ngicCapabilities = ncapabilities;
}
qemu: Implement the driver backend for virNodeGetSEVInfo() Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:55 +00:00
virSEVCapabilityPtr
virQEMUCapsGetSEVCapabilities(virQEMUCapsPtr qemuCaps)
{
return qemuCaps->sevCapabilities;
}
Move command/event capabilities detection out of QEMU monitor code The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 14:54:02 +00:00
static int
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsProbeQMPCommands(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
Move command/event capabilities detection out of QEMU monitor code The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 14:54:02 +00:00
{
char **commands = NULL;
int ncommands;
if ((ncommands = qemuMonitorGetCommands(mon, &commands)) < 0)
return -1;
qemu: Make probing for commands declarative
2013-06-19 08:00:10 +00:00
virQEMUCapsProcessStringFlags(qemuCaps,
ARRAY_CARDINALITY(virQEMUCapsCommands),
virQEMUCapsCommands,
ncommands, commands);
qemu: Drop virQEMUCapsFreeStringList The implementation matches virStringListFreeCount. The only difference between the two functions is the ordering of their parameters. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-03 20:31:26 +00:00
virStringListFreeCount(commands, ncommands);
Move command/event capabilities detection out of QEMU monitor code The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 14:54:02 +00:00
qemu: capabilities: Detect active block commit via QMP schema probing if possible For versions where we can probe that the arguments are optional we can perform the probing by a schema query rather than sending a separate command to do so. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-08-14 15:53:05 +00:00
/* Probe for active commit of qemu 2.1. We don't need to query directly
* if we have QMP schema support */
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_QMP_SCHEMA) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_BLOCK_COMMIT) &&
blockjob: turn on qemu capability bit for active commit Use the probing functionality added in the last patch to turn on a capability bit when active commit is present, and gate active commit on that capability. For my own reference: the difference between BLOCKJOB_SYNC and BLOCKJOB_ASYNC is whether qemu generated an event at the conclusion of blockpull; basically, RHEL 6.2 was the only release of qemu that has the sync semantics and lacks the event. RHEL 6.3 added blockcopy, but also picked up on the upstream style of qemu generating events. As no one is likely to backport active commit to RHEL 6.2, it's safe for blockcommit to always require async blockjob support. Modifying qemucapabilitiestest is painful; the .replies files would be so much easier if they had comments correlating which command generated the given reply. Maybe I'll fix that up later... * src/qemu/qemu_capabilities.h (QEMU_CAPS_ACTIVE_COMMIT): New capability. * src/qemu/qemu_driver.c (qemuDomainBlockCommit): Use the new bit * src/qemu/qemu_capabilities.c (virQEMUCaps): Name the new bit. (virQEMUCapsProbeQMPCommands): Set it. * tests/qemucapabilitiesdata/caps_1.3.1-1.replies: Update. * tests/qemucapabilitiesdata/caps_1.4.2-1.replies: Likewise. * tests/qemucapabilitiesdata/caps_1.5.3-1.replies: Likewise. * tests/qemucapabilitiesdata/caps_1.6.0-1.replies: Likewise. * tests/qemucapabilitiesdata/caps_1.6.50-1.replies: Likewise. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-17 03:42:49 +00:00
qemuMonitorSupportsActiveCommit(mon))
virQEMUCapsSet(qemuCaps, QEMU_CAPS_ACTIVE_COMMIT);
Move command/event capabilities detection out of QEMU monitor code The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 14:54:02 +00:00
return 0;
}
static int
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsProbeQMPEvents(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
Move command/event capabilities detection out of QEMU monitor code The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 14:54:02 +00:00
{
char **events = NULL;
int nevents;
if ((nevents = qemuMonitorGetEvents(mon, &events)) < 0)
return -1;
qemu: Make probing for events declarative
2013-06-19 07:24:54 +00:00
virQEMUCapsProcessStringFlags(qemuCaps,
ARRAY_CARDINALITY(virQEMUCapsEvents),
virQEMUCapsEvents,
nevents, events);
qemu: Drop virQEMUCapsFreeStringList The implementation matches virStringListFreeCount. The only difference between the two functions is the ordering of their parameters. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-03 20:31:26 +00:00
virStringListFreeCount(events, nevents);
Move command/event capabilities detection out of QEMU monitor code The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 14:54:02 +00:00
return 0;
}
qemu_capabilities: Separate out device props fetching The code is generic enough to be reused. Move it into a separate function. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 12:39:43 +00:00
static int
virQEMUCapsProbeQMPGenericProps(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon,
virQEMUCapsObjectTypeProps *props,
size_t nprops,
virQEMUCapsObjectTypePropsCB propsGetCB)
{
int nvalues;
char **values;
size_t i;
for (i = 0; i < nprops; i++) {
const char *type = props[i].type;
int cap = props[i].capsCondition;
if (cap >= 0 && !virQEMUCapsGet(qemuCaps, cap))
continue;
if ((nvalues = propsGetCB(mon, type, &values)) < 0)
return -1;
virQEMUCapsProcessStringFlags(qemuCaps,
props[i].nprops,
props[i].props,
nvalues, values);
virStringListFreeCount(values, nvalues);
}
return 0;
}
Move command/event capabilities detection out of QEMU monitor code The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 14:54:02 +00:00
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
static int
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
virQEMUCapsProbeQMPDevices(virQEMUCapsPtr qemuCaps,
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
qemuMonitorPtr mon)
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
{
int nvalues;
char **values;
if ((nvalues = qemuMonitorGetObjectTypes(mon, &values)) < 0)
return -1;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsProcessStringFlags(qemuCaps,
ARRAY_CARDINALITY(virQEMUCapsObjectTypes),
virQEMUCapsObjectTypes,
nvalues, values);
qemu: Drop virQEMUCapsFreeStringList The implementation matches virStringListFreeCount. The only difference between the two functions is the ordering of their parameters. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-03 20:31:26 +00:00
virStringListFreeCount(values, nvalues);
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
qemu_capabilities: Separate out device props fetching The code is generic enough to be reused. Move it into a separate function. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 12:39:43 +00:00
if (virQEMUCapsProbeQMPGenericProps(qemuCaps,
mon,
virQEMUCapsDeviceProps,
ARRAY_CARDINALITY(virQEMUCapsDeviceProps),
qemuMonitorGetDeviceProps) < 0)
return -1;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu_capabilities: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD This capability tracks if memory-backend-file has discard-data attribute or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-20 08:25:49 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QOM_LIST_PROPERTIES) &&
virQEMUCapsProbeQMPGenericProps(qemuCaps,
mon,
virQEMUCapsObjectProps,
ARRAY_CARDINALITY(virQEMUCapsObjectProps),
qemuMonitorGetObjectProps) < 0)
return -1;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
return 0;
}
qemu: ensure default machine types don't change if QEMU changes It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable to change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-03 12:29:26 +00:00
/* Historically QEMU x86 targets defaulted to 'pc' machine type but
* in future x86_64 might switch to 'q35'. Such a change is considered
* an ABI break from libvirt's POV. Other QEMU targets may not declare
* a default machine at all, causing libvirt to use the first reported
* machine in the list.
*
* Here we record a preferred default machine for all arches, so
* that we're not vulnerable to changes in QEMU defaults or machine
* list ordering.
*/
qemu: Make sure preferredMachines is not missing any entry With the current implementation, adding a new architecture and not updating preferredMachines accordingly will not cause a build failure, making it very likely that subtle bugs will be introduced in the process. Rework the code so that such issues will be caught by the compiler. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-08-23 16:46:52 +00:00
static const char *preferredMachines[] =
qemu: ensure default machine types don't change if QEMU changes It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable to change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-03 12:29:26 +00:00
{
qemu: Make sure preferredMachines is not missing any entry With the current implementation, adding a new architecture and not updating preferredMachines accordingly will not cause a build failure, making it very likely that subtle bugs will be introduced in the process. Rework the code so that such issues will be caught by the compiler. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-08-23 16:46:52 +00:00
NULL, /* VIR_ARCH_NONE (not a real arch :) */
"clipper", /* VIR_ARCH_ALPHA */
NULL, /* VIR_ARCH_ARMV6L (no QEMU impl) */
"integratorcp", /* VIR_ARCH_ARMV7L */
"integratorcp", /* VIR_ARCH_ARMV7B */
"integratorcp", /* VIR_ARCH_AARCH64 */
"axis-dev88", /* VIR_ARCH_CRIS */
"pc", /* VIR_ARCH_I686 */
NULL, /* VIR_ARCH_ITANIUM (doesn't exist in QEMU any more) */
"lm32-evr", /* VIR_ARCH_LM32 */
"mcf5208evb", /* VIR_ARCH_M68K */
"petalogix-s3adsp1800", /* VIR_ARCH_MICROBLAZE */
"petalogix-s3adsp1800", /* VIR_ARCH_MICROBLAZEEL */
"malta", /* VIR_ARCH_MIPS */
"malta", /* VIR_ARCH_MIPSEL */
"malta", /* VIR_ARCH_MIPS64 */
"malta", /* VIR_ARCH_MIPS64EL */
"or1k-sim", /* VIR_ARCH_OR32 */
NULL, /* VIR_ARCH_PARISC (no QEMU impl) */
NULL, /* VIR_ARCH_PARISC64 (no QEMU impl) */
"g3beige", /* VIR_ARCH_PPC */
"g3beige", /* VIR_ARCH_PPCLE */
"pseries", /* VIR_ARCH_PPC64 */
"pseries", /* VIR_ARCH_PPC64LE */
"bamboo", /* VIR_ARCH_PPCEMB */
util: add RISC-V architectures Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-08-22 09:15:22 +00:00
"spike_v1.10", /* VIR_ARCH_RISCV32 */
"spike_v1.10", /* VIR_ARCH_RISCV64 */
qemu: Make sure preferredMachines is not missing any entry With the current implementation, adding a new architecture and not updating preferredMachines accordingly will not cause a build failure, making it very likely that subtle bugs will be introduced in the process. Rework the code so that such issues will be caught by the compiler. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-08-23 16:46:52 +00:00
NULL, /* VIR_ARCH_S390 (no QEMU impl) */
"s390-ccw-virtio", /* VIR_ARCH_S390X */
"shix", /* VIR_ARCH_SH4 */
util: add RISC-V architectures Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-08-22 09:15:22 +00:00
qemu: Make sure preferredMachines is not missing any entry With the current implementation, adding a new architecture and not updating preferredMachines accordingly will not cause a build failure, making it very likely that subtle bugs will be introduced in the process. Rework the code so that such issues will be caught by the compiler. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-08-23 16:46:52 +00:00
"shix", /* VIR_ARCH_SH4EB */
"SS-5", /* VIR_ARCH_SPARC */
"sun4u", /* VIR_ARCH_SPARC64 */
"puv3", /* VIR_ARCH_UNICORE32 */
"pc", /* VIR_ARCH_X86_64 */
util: add RISC-V architectures Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-08-22 09:15:22 +00:00
qemu: Make sure preferredMachines is not missing any entry With the current implementation, adding a new architecture and not updating preferredMachines accordingly will not cause a build failure, making it very likely that subtle bugs will be introduced in the process. Rework the code so that such issues will be caught by the compiler. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-08-23 16:46:52 +00:00
"sim", /* VIR_ARCH_XTENSA */
"sim", /* VIR_ARCH_XTENSAEB */
qemu: ensure default machine types don't change if QEMU changes It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable to change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-03 12:29:26 +00:00
};
qemu: Make sure preferredMachines is not missing any entry With the current implementation, adding a new architecture and not updating preferredMachines accordingly will not cause a build failure, making it very likely that subtle bugs will be introduced in the process. Rework the code so that such issues will be caught by the compiler. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-08-23 16:46:52 +00:00
verify(ARRAY_CARDINALITY(preferredMachines) == VIR_ARCH_LAST);
qemu: ensure default machine types don't change if QEMU changes It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable to change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-03 12:29:26 +00:00
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
static int
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
{
qemuMonitorMachineInfoPtr *machines = NULL;
int nmachines = 0;
int ret = -1;
size_t i;
qemu: ensure default machine types don't change if QEMU changes It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable to change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-03 12:29:26 +00:00
ssize_t defIdx = -1;
ssize_t preferredIdx = -1;
const char *preferredMachine = preferredMachines[qemuCaps->arch];
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
if ((nmachines = qemuMonitorGetMachines(mon, &machines)) < 0)
qemu: Resolve Coverity NEGATIVE_RETURNS Coverity notes that if qemuMonitorGetMachines() returns a negative nmachines value, then the code at the cleanup label will have issues. Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-04 21:15:51 +00:00
return -1;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
Adapt to VIR_ALLOC and virAsprintf in src/qemu/*
2013-07-04 10:14:12 +00:00
if (VIR_ALLOC_N(qemuCaps->machineTypes, nmachines) < 0)
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
goto cleanup;
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < nmachines; i++) {
qemu: cap: Refactor access to array in virQEMUCapsProbeQMPMachineTypes Use a temporary pointer rather than always recalculating the index in a very verbose way.
2016-07-29 08:35:48 +00:00
struct virQEMUCapsMachineType *mach;
Don't expose 'none' machine type to capabilities The 'none' machine type is something only intended for use by libvirt probing capabilities. It isn't something that is useful for running real VM instances. As such it should not be exposed to users in the capabilities. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-11-06 07:31:24 +00:00
if (STREQ(machines[i]->name, "none"))
continue;
qemu: cap: Refactor access to array in virQEMUCapsProbeQMPMachineTypes Use a temporary pointer rather than always recalculating the index in a very verbose way.
2016-07-29 08:35:48 +00:00
mach = &(qemuCaps->machineTypes[qemuCaps->nmachineTypes++]);
if (VIR_STRDUP(mach->alias, machines[i]->alias) < 0 ||
VIR_STRDUP(mach->name, machines[i]->name) < 0)
qemu: capabilities: fix machine name/canonical swappage Things are supposed to look like: <machine canonical='pc-0.12'>pc</machine> But are currently swapped. This can cause many VMs to revert to having machine type='pc' which will affect save/restore across qemu upgrades.
2012-12-07 16:30:34 +00:00
goto cleanup;
qemu: cap: Refactor access to array in virQEMUCapsProbeQMPMachineTypes Use a temporary pointer rather than always recalculating the index in a very verbose way.
2016-07-29 08:35:48 +00:00
mach->maxCpus = machines[i]->maxCpus;
qemu: capabilities: Extract availability of new cpu hotplug for machine types QEMU reports whether 'query-hotpluggable-cpus' is supported for a given machine type. Extract and cache the information using the capability cache. When copying the capabilities for a new start of qemu, mask out the presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type doesn't support hotpluggable cpus.
2016-07-29 07:45:19 +00:00
mach->hotplugCpus = machines[i]->hotplugCpus;
qemu: cap: Refactor access to array in virQEMUCapsProbeQMPMachineTypes Use a temporary pointer rather than always recalculating the index in a very verbose way.
2016-07-29 08:35:48 +00:00
qemu: ensure default machine types don't change if QEMU changes It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable to change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-03 12:29:26 +00:00
if (preferredMachine &&
(STREQ_NULLABLE(mach->alias, preferredMachine) ||
STREQ(mach->name, preferredMachine))) {
preferredIdx = qemuCaps->nmachineTypes - 1;
}
qemu: record the QEMU default machine in capabilities We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 12:18:27 +00:00
if (machines[i]->isDefault) {
mach->qemuDefault = true;
Fix segmentation fault when accessing default qemu machine type This patch fixes a segmentation fault when creating new virtual machines using QEMU. The segmentation fault is caused by commit f41830680e40d3ec845cefd25419bd87414b9ccf and commit cbb6ec42e2447d7920b30d66923b2a2b2670133b. In virQEMUCapsProbeQMPMachineTypes, when copying machines to qemuCaps, "none" is skipped. Therefore, the value of i and "qemuCaps->nmachineTypes - 1" do not always match. However, defIdx value (used to call virQEMUCapsSetDefaultMachine) is set using the value in i when the array elements are in qemuCaps->nmachineTypes - 1. So, when libvirt tries to create virtual machines using the default machine type, qemuCaps->machineTypes[defIdx] is accessed and since the defIdx is NULL, it results in segmentation fault. Signed-off-by: Yudai Yamagishi <yummy@sfc.wide.ad.jp> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-12-17 08:33:19 +00:00
defIdx = qemuCaps->nmachineTypes - 1;
qemu: record the QEMU default machine in capabilities We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 12:18:27 +00:00
}
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
}
qemu: Fix up the default machine type for QMP probing The default machine type must be stored in the first element of the caps->machineTypes array. This was done for help output parsing but not for QMP probing. Added a helper function qemuSetDefaultMachine to apply the same fix up for both probing methods. Further, it was necessary to set caps->nmachineTypes after QMP probing. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2012-11-30 18:22:42 +00:00
qemu: ensure default machine types don't change if QEMU changes It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable to change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-03 12:29:26 +00:00
/*
* We'll prefer to use our own historical default machine
* to avoid mgmt apps seeing semantics changes when QEMU
* alters its defaults.
*
* Our preferred machine might have been compiled out of
* QEMU at build time though, so we still fallback to honouring
* QEMU's reported default in that case
*/
if (preferredIdx == -1)
preferredIdx = defIdx;
if (preferredIdx != -1)
virQEMUCapsSetDefaultMachine(qemuCaps, preferredIdx);
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
ret = 0;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
cleanup:
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < nmachines; i++)
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemuMonitorMachineInfoFree(machines[i]);
VIR_FREE(machines);
return ret;
}
qemu: Separate fetching CPU definitions from filling qemuCaps virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-07 10:21:48 +00:00
virDomainCapsCPUModelsPtr
virQEMUCapsFetchCPUDefinitions(qemuMonitorPtr mon)
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
{
qemu: Separate fetching CPU definitions from filling qemuCaps virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-07 10:21:48 +00:00
virDomainCapsCPUModelsPtr models = NULL;
qemuMonitorCPUDefInfoPtr *cpus = NULL;
int ncpus = 0;
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
size_t i;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
if ((ncpus = qemuMonitorGetCPUDefinitions(mon, &cpus)) < 0)
qemu: Avoid comparing size_t with -1 ncpus would be -1 on error and the cleanup for loop would not be skipped in this case. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-12-11 13:34:20 +00:00
return NULL;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (!(models = virDomainCapsCPUModelsNew(ncpus)))
qemu: Separate fetching CPU definitions from filling qemuCaps virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-07 10:21:48 +00:00
goto error;
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
for (i = 0; i < ncpus; i++) {
qemu: Add support for unavailable-features QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the CPU model can be used without modifications. We can use unavailable-features for providing CPU model usability info in domain capabilities XML: <domainCapabilities> ... <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'> <model fallback='allow'>Skylake-Client</model> ... </mode> <mode name='custom' supported='yes'> <model usable='yes'>qemu64</model> <model usable='yes'>qemu32</model> <model usable='no'>phenom</model> <model usable='yes'>pentium3</model> <model usable='yes'>pentium2</model> <model usable='yes'>pentium</model> <model usable='yes'>n270</model> <model usable='yes'>kvm64</model> <model usable='yes'>kvm32</model> <model usable='yes'>coreduo</model> <model usable='yes'>core2duo</model> <model usable='no'>athlon</model> <model usable='yes'>Westmere</model> <model usable='yes'>Skylake-Client</model> ... </mode> </cpu> ... </domainCapabilities> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 11:08:12 +00:00
virDomainCapsCPUUsable usable = VIR_DOMCAPS_CPU_USABLE_UNKNOWN;
if (cpus[i]->usable == VIR_TRISTATE_BOOL_YES)
usable = VIR_DOMCAPS_CPU_USABLE_YES;
else if (cpus[i]->usable == VIR_TRISTATE_BOOL_NO)
usable = VIR_DOMCAPS_CPU_USABLE_NO;
conf: Add usability blockers to virDomainCapsCPUModel When a hypervisor marks a CPU model as unusable on the current host, it may also give us a list of features which prevent the model from being usable. Storing this list in virDomainCapsCPUModel will help the CPU driver with creating a host-model CPU configuration. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-19 16:35:08 +00:00
if (virDomainCapsCPUModelsAddSteal(models, &cpus[i]->name, usable,
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 08:45:49 +00:00
&cpus[i]->blockers) < 0)
qemu: Separate fetching CPU definitions from filling qemuCaps virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-07 10:21:48 +00:00
goto error;
qemu: Use virDomainCapsCPUModels for cpuDefinitions The list of supported CPU models in domain capabilities is stored in virDomainCapsCPUModels. Let's use the same object for storing CPU models in QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 10:51:01 +00:00
}
cleanup:
for (i = 0; i < ncpus; i++)
qemuMonitorCPUDefInfoFree(cpus[i]);
VIR_FREE(cpus);
qemu: Separate fetching CPU definitions from filling qemuCaps virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-07 10:21:48 +00:00
return models;
error:
virObjectUnref(models);
models = NULL;
goto cleanup;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
}
qemu: Separate fetching CPU definitions from filling qemuCaps virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-07 10:21:48 +00:00
int
virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon,
bool tcg)
{
virDomainCapsCPUModelsPtr models = NULL;
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_DEFINITIONS))
return 0;
if (!(models = virQEMUCapsFetchCPUDefinitions(mon)))
return -1;
if (tcg || !virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
qemuCaps->tcgCPUModels = models;
else
qemuCaps->kvmCPUModels = models;
return 0;
}
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
static int
virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
qemuMonitorPtr mon,
bool tcg)
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
{
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
qemuMonitorCPUModelInfoPtr modelInfo = NULL;
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
qemuMonitorCPUModelInfoPtr nonMigratable = NULL;
virHashTablePtr hash = NULL;
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
const char *model;
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 12:53:51 +00:00
qemuMonitorCPUModelExpansionType type;
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virDomainVirtType virtType;
virQEMUCapsHostCPUDataPtr cpuData;
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
int ret = -1;
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
return 0;
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
if (tcg || !virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virtType = VIR_DOMAIN_VIRT_QEMU;
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
model = "max";
} else {
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virtType = VIR_DOMAIN_VIRT_KVM;
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
model = "host";
}
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
cpuData = virQEMUCapsGetHostCPUData(qemuCaps, virtType);
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 12:53:51 +00:00
/* Some x86_64 features defined in cpu_map.xml use spelling which differ
* from the one preferred by QEMU. Static expansion would give us only the
* preferred spelling, thus we need to do a full expansion on the result of
* the initial static expansion to get all variants of all features.
*/
if (ARCH_IS_X86(qemuCaps->arch))
type = QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC_FULL;
else
type = QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC;
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
if (qemuMonitorGetCPUModelExpansion(mon, type, model, true, &modelInfo) < 0)
goto cleanup;
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
/* Try to check migratability of each feature. */
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
if (modelInfo &&
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
qemuMonitorGetCPUModelExpansion(mon, type, model, false,
&nonMigratable) < 0)
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
goto cleanup;
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
if (nonMigratable) {
qemuMonitorCPUPropertyPtr prop;
qemuMonitorCPUPropertyPtr nmProp;
size_t i;
if (!(hash = virHashCreate(0, NULL)))
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
goto cleanup;
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
for (i = 0; i < modelInfo->nprops; i++) {
prop = modelInfo->props + i;
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
if (virHashAddEntry(hash, prop->name, prop) < 0)
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
goto cleanup;
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
}
for (i = 0; i < nonMigratable->nprops; i++) {
nmProp = nonMigratable->props + i;
if (!(prop = virHashLookup(hash, nmProp->name)) ||
prop->type != QEMU_MONITOR_CPU_PROPERTY_BOOLEAN ||
prop->type != nmProp->type)
continue;
qemu: Check non-migratable host CPU features CPU features which change their value from disabled to enabled between two calls to query-cpu-model-expansion (the first with no extra properties set and the second with 'migratable' property set to false) can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo. Since the code consuming qemuMonitorCPUModelInfo currently ignores the migratable flag, this change is effectively changing the CPU model advertised in domain capabilities to contain all features (even those which block migration). And this matches what we do for QEMU older than 2.9.0, when we detect all CPUID bits ourselves without asking QEMU. As a result of this change <cpu mode='host-model'> <feature name='invtsc' policy='require'/> </cpu> will work with all QEMU versions. Such CPU definition would be forbidden with QEMU >= 2.9.0 without this patch. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 09:00:32 +00:00
if (prop->value.boolean) {
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
prop->migratable = VIR_TRISTATE_BOOL_YES;
qemu: Check non-migratable host CPU features CPU features which change their value from disabled to enabled between two calls to query-cpu-model-expansion (the first with no extra properties set and the second with 'migratable' property set to false) can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo. Since the code consuming qemuMonitorCPUModelInfo currently ignores the migratable flag, this change is effectively changing the CPU model advertised in domain capabilities to contain all features (even those which block migration). And this matches what we do for QEMU older than 2.9.0, when we detect all CPUID bits ourselves without asking QEMU. As a result of this change <cpu mode='host-model'> <feature name='invtsc' policy='require'/> </cpu> will work with all QEMU versions. Such CPU definition would be forbidden with QEMU >= 2.9.0 without this patch. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 09:00:32 +00:00
} else if (nmProp->value.boolean) {
prop->value.boolean = true;
prop->migratable = VIR_TRISTATE_BOOL_NO;
}
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
}
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
modelInfo->migratability = true;
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
}
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
VIR_STEAL_PTR(cpuData->info, modelInfo);
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
ret = 0;
cleanup:
virHashFree(hash);
qemuMonitorCPUModelInfoFree(nonMigratable);
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
qemuMonitorCPUModelInfoFree(modelInfo);
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:58:41 +00:00
return ret;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
}
qemu_capabilities: Introduce virQEMUCapsGetCPUFeatures The function creates a list of all (or migratable only) CPU features supported by QEMU. It works by looking at the CPU model info returned by query-cpu-model-expansion QMP command. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Collin Walling <walling@linux.ibm.com>
2018-05-15 20:03:19 +00:00
/**
* Get NULL terminated list of features supported by QEMU.
*
* Returns -1 on error,
* 0 on success (@features will be NULL if QEMU does not support this),
* 1 when @features is filled in, but migratability info is not available.
*/
int
virQEMUCapsGetCPUFeatures(virQEMUCapsPtr qemuCaps,
virDomainVirtType virtType,
bool migratable,
char ***features)
{
virQEMUCapsHostCPUDataPtr data;
char **list;
size_t i;
size_t n;
int ret = -1;
*features = NULL;
data = virQEMUCapsGetHostCPUData(qemuCaps, virtType);
if (!data->info)
return 0;
if (VIR_ALLOC_N(list, data->info->nprops + 1) < 0)
return -1;
n = 0;
for (i = 0; i < data->info->nprops; i++) {
qemuMonitorCPUPropertyPtr prop = data->info->props + i;
if (migratable && prop->migratable == VIR_TRISTATE_BOOL_NO)
continue;
if (VIR_STRDUP(list[n++], prop->name) < 0)
goto cleanup;
}
VIR_STEAL_PTR(*features, list);
if (migratable && !data->info->migratability)
ret = 1;
else
ret = 0;
cleanup:
virStringListFree(list);
return ret;
}
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
struct tpmTypeToCaps {
int type;
qemu: enum cleanups in "src/qemu/*" As we are doing with the enum structures, a cleanup in "src/qemu/" directory was done now. All the enums that were defined in the header files were converted to typedefs in this directory. This patch includes all the adjustments to remove conflicts when you do this kind of change. "Enum-to-typedef"'s conversions were made in "src/qemu/qemu_{capabilities, domain, migration, hotplug}.h". Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
2014-06-15 16:32:56 +00:00
virQEMUCapsFlags caps;
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
};
static const struct tpmTypeToCaps virQEMUCapsTPMTypesToCaps[] = {
{
.type = VIR_DOMAIN_TPM_TYPE_PASSTHROUGH,
.caps = QEMU_CAPS_DEVICE_TPM_PASSTHROUGH,
},
qemu: Extend QEMU capabilities with 'tpm-emulator' Extend the QEMU capabilities with tpm-emulator support. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2017-04-04 16:22:31 +00:00
{
.type = VIR_DOMAIN_TPM_TYPE_EMULATOR,
.caps = QEMU_CAPS_DEVICE_TPM_EMULATOR,
},
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
};
const struct tpmTypeToCaps virQEMUCapsTPMModelsToCaps[] = {
{
.type = VIR_DOMAIN_TPM_MODEL_TIS,
.caps = QEMU_CAPS_DEVICE_TPM_TIS,
},
qemu: Extend the capabilities with tpm-crb device QEMU on x86_64 (since v2.12) can support tpm-crb devices. Introduce qemu capabilities for this device. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-04-26 17:42:17 +00:00
{
.type = VIR_DOMAIN_TPM_MODEL_CRB,
.caps = QEMU_CAPS_DEVICE_TPM_CRB,
},
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
};
static int
virQEMUCapsProbeQMPTPM(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
Convert 'int i' to 'size_t i' in src/qemu files Convert the type of loop iterators named 'i', 'j', k', 'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or 'unsigned int', also santizing 'ii', 'jj', 'kk' to use the normal 'i', 'j', 'k' naming Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-07-08 14:09:33 +00:00
int nentries;
size_t i;
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
char **entries = NULL;
Check for QMP query-tpm-models Check for QMP query-tpm-models and set a capability flag. Do not use this QMP command if it is not supported. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
2013-04-15 20:46:53 +00:00
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
if ((nentries = qemuMonitorGetTPMModels(mon, &entries)) < 0)
return -1;
if (nentries > 0) {
for (i = 0; i < ARRAY_CARDINALITY(virQEMUCapsTPMModelsToCaps); i++) {
const char *needle = virDomainTPMModelTypeToString(
virQEMUCapsTPMModelsToCaps[i].type);
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
if (virStringListHasString((const char **)entries, needle))
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
virQEMUCapsSet(qemuCaps,
virQEMUCapsTPMModelsToCaps[i].caps);
}
}
virstring: Unify string list function names We have couple of functions that operate over NULL terminated lits of strings. However, our naming sucks: virStringJoin virStringFreeList virStringFreeListCount virStringArrayHasString virStringGetFirstWithPrefix We can do better: virStringListJoin virStringListFree virStringListFreeCount virStringListHasString virStringListGetFirstWithPrefix Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-11-25 08:18:35 +00:00
virStringListFree(entries);
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
if ((nentries = qemuMonitorGetTPMTypes(mon, &entries)) < 0)
return -1;
if (nentries > 0) {
for (i = 0; i < ARRAY_CARDINALITY(virQEMUCapsTPMTypesToCaps); i++) {
const char *needle = virDomainTPMBackendTypeToString(
virQEMUCapsTPMTypesToCaps[i].type);
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
if (virStringListHasString((const char **)entries, needle))
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
virQEMUCapsSet(qemuCaps, virQEMUCapsTPMTypesToCaps[i].caps);
}
}
virstring: Unify string list function names We have couple of functions that operate over NULL terminated lits of strings. However, our naming sucks: virStringJoin virStringFreeList virStringFreeListCount virStringArrayHasString virStringGetFirstWithPrefix We can do better: virStringListJoin virStringListFree virStringListFreeCount virStringListHasString virStringListGetFirstWithPrefix Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-11-25 08:18:35 +00:00
virStringListFree(entries);
Convert QMP strings into QEMU capability bits Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Corey Bryant <coreyb@linux.vnet.ibm.com> Tested-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
2013-04-12 20:55:45 +00:00
return 0;
}
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
Make non-KVM machines work with QMP probing When there is no 'qemu-kvm' binary and the emulator used for a machine is, for example, 'qemu-system-x86_64' that, by default, runs without kvm enabled, libvirt still supplies '-no-kvm' option to this process, even though it does not recognize such option (making the start of a domain fail in that case). This patch fixes building a command-line for QEMU machines without KVM acceleration and is based on following assumptions: - QEMU_CAPS_KVM flag means that QEMU is running KVM accelerated machines by default (without explicitly requesting that using a command-line option). It is the closest to the truth according to the code with the only exception being the comment next to the flag, so it's fixed in this patch as well. - QEMU_CAPS_ENABLE_KVM flag means that QEMU is, by default, running without KVM acceleration and in case we need KVM acceleration it needs to be explicitly instructed to do so. This is partially true for the past (this option essentially means that QEMU recognizes the '-enable-kvm' option, even though it's almost the same).
2012-10-31 07:31:49 +00:00
static int
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsProbeQMPKVMState(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
Make non-KVM machines work with QMP probing When there is no 'qemu-kvm' binary and the emulator used for a machine is, for example, 'qemu-system-x86_64' that, by default, runs without kvm enabled, libvirt still supplies '-no-kvm' option to this process, even though it does not recognize such option (making the start of a domain fail in that case). This patch fixes building a command-line for QEMU machines without KVM acceleration and is based on following assumptions: - QEMU_CAPS_KVM flag means that QEMU is running KVM accelerated machines by default (without explicitly requesting that using a command-line option). It is the closest to the truth according to the code with the only exception being the comment next to the flag, so it's fixed in this patch as well. - QEMU_CAPS_ENABLE_KVM flag means that QEMU is, by default, running without KVM acceleration and in case we need KVM acceleration it needs to be explicitly instructed to do so. This is partially true for the past (this option essentially means that QEMU recognizes the '-enable-kvm' option, even though it's almost the same).
2012-10-31 07:31:49 +00:00
{
bool enabled = false;
bool present = false;
if (qemuMonitorGetKVMState(mon, &enabled, &present) < 0)
return -1;
qemu: Clarify QEMU_CAPS_KVM This capability is documented as having one meaning (whether KVM is enabled by default) but is actually assigned two other meanings over its life: whether the query-kvm QMP command is available at first, and later on whether KVM is usable / was used during probing. Since the query-kvm QMP command was available in 1.5.0, we can avoid probing for it; additionally, we can simplify the logic by setting the flag when it applies instead of initially setting it and then clearing it when it doesn't. The flag's description is also updated to reflect reality. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2018-09-13 14:56:55 +00:00
if (present && enabled)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_KVM);
Make non-KVM machines work with QMP probing When there is no 'qemu-kvm' binary and the emulator used for a machine is, for example, 'qemu-system-x86_64' that, by default, runs without kvm enabled, libvirt still supplies '-no-kvm' option to this process, even though it does not recognize such option (making the start of a domain fail in that case). This patch fixes building a command-line for QEMU machines without KVM acceleration and is based on following assumptions: - QEMU_CAPS_KVM flag means that QEMU is running KVM accelerated machines by default (without explicitly requesting that using a command-line option). It is the closest to the truth according to the code with the only exception being the comment next to the flag, so it's fixed in this patch as well. - QEMU_CAPS_ENABLE_KVM flag means that QEMU is, by default, running without KVM acceleration and in case we need KVM acceleration it needs to be explicitly instructed to do so. This is partially true for the past (this option essentially means that QEMU recognizes the '-enable-kvm' option, even though it's almost the same).
2012-10-31 07:31:49 +00:00
return 0;
}
qemu: detect -machine mem-merge capability * src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d813; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
2013-05-14 05:25:49 +00:00
struct virQEMUCapsCommandLineProps {
const char *option;
const char *param;
int flag;
};
static struct virQEMUCapsCommandLineProps virQEMUCapsCommandLine[] = {
{ "machine", "mem-merge", QEMU_CAPS_MEM_MERGE },
qemu: add QEMU_CAPS_MACHINE_VMPORT_OPT Set the capability based on qmp query, or qemu version. The qmp query includes vmport with 2.2, but no longer with 2.3. It lists only non-machine specific capabilities, so check the qemu version too until a machine-specific query is supported.
2015-04-02 16:43:47 +00:00
{ "machine", "vmport", QEMU_CAPS_MACHINE_VMPORT_OPT },
qemu: Support discard for disk QEMU introduced "discard" option for drive since commit a9384aff53, <...> @var{discard} is one of "ignore" (or "off") or "unmap" (or "on") and controls whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap}) requests are ignored or passed to the filesystem. Some machine types may not support discard requests. </...> This patch exposes the support in libvirt. QEMU supported "discard" for "-drive" since v1.5.0-rc0: % git tag --contains a9384aff53 contains v1.5.0-rc0 v1.5.0-rc1 So this only detects the capability bit using virQEMUCapsProbeQMPCommandLine.
2013-05-14 12:44:54 +00:00
{ "drive", "discard", QEMU_CAPS_DRIVE_DISCARD },
qemu: Add support for zero-detection writes Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-12-14 08:35:20 +00:00
{ "drive", "detect-zeroes", QEMU_CAPS_DRIVE_DETECT_ZEROES },
qemu: rename QEMU_CAPS_MLOCK to QEMU_CAPS_REALTIME_MLOCK Purely cosmetic change to be consistent with the other names. Signed-off-by: Henning Schild <henning.schild@siemens.com>
2016-07-25 12:44:16 +00:00
{ "realtime", "mlock", QEMU_CAPS_REALTIME_MLOCK },
qemu: add "-boot strict" to commandline whenever possible This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=888635 (which was already closed as CANTFIX because the qemu "-boot strict" commandline option wasn't available at the time). Problem: you couldn't have a domain that used PXE to boot, but also had an un-bootable disk device *even if that disk wasn't listed in the boot order*, because if PXE timed out (e.g. due to the bridge forwarding delay), the BIOS would move on to the next target, which would be the unbootable disk device (again - even though it wasn't given a boot order), and get stuck at a "BOOT DISK FAILURE, PRESS ANY KEY" message until a user intervened. The solution available since sometime around QEMU 1.5, is to add "-boot strict=on" to *every* qemu command. When this is done, if any devices have a boot order specified, then QEMU will *only* attempt to boot from those devices that have an explicit boot order, ignoring the rest.
2013-12-02 12:07:12 +00:00
{ "boot-opts", "strict", QEMU_CAPS_BOOT_STRICT },
qemu: check for reboot-timeout on monitor The support for <boot rebootTimeout="12345"/> was added before we were checking for qemu command line options in QMP, so we haven't properly adapted virQEMUCaps when using it and thus we report unsupported option with new enough qemu. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1042690 Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2013-12-13 13:51:24 +00:00
{ "boot-opts", "reboot-timeout", QEMU_CAPS_REBOOT_TIMEOUT },
qemu: add capability probing for splash-timeout Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-08-22 11:42:46 +00:00
{ "boot-opts", "splash-time", QEMU_CAPS_SPLASH_TIMEOUT },
spice: detect if qemu can disable file transfer spice-server offers an API to disable file transfer messages on the agent channel between the client and the guest. This is supported in qemu through the disable-agent-file-xfer option. This patch detects if QEMU supports this option, and add a capability if does. Signed-off-by: Francesco Romani <fromani@redhat.com>
2014-01-16 16:11:14 +00:00
{ "spice", "disable-agent-file-xfer", QEMU_CAPS_SPICE_FILE_XFER_DISABLE },
Add support for timestamping QEMU logs QEMU commit 5e2ac51 added a boolean '-msg timestamp=[on|off]' option, which can enable timestamps on errors: $ qemu-system-x86_64 -msg timestamp=on zghhdorf 2014-04-09T13:25:46.779484Z qemu-system-x86_64: -msg timestamp=on: could not open disk image zghhdorf: Could not open 'zghhdorf': No such file or directory Enable this timestamp if the QEMU binary supports it. Add a 'log_timestamp' option to qemu.conf for disabling this behavior.
2014-04-09 13:23:45 +00:00
{ "msg", "timestamp", QEMU_CAPS_MSG_TIMESTAMP },
qemu: newer -numa parameter capability probing When qemu switched to using OptsVisitor for -numa parameter, it did two things in the same patch. One of them is that the numa parameter is now visible in "query-command-line-options", the second one is that it enabled using disjoint cpu ranges for -numa specification. This will be used in later patch. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-06-17 11:43:19 +00:00
{ "numa", NULL, QEMU_CAPS_NUMA },
qemu: Add Qemu capability for bps_max and friends Add the capability to detect if the qemu binary have the capability to use bps_max and friends Add a value in the enum virQEMUCapsFlags for the qemu capability. Set it with virQEMUCapsSet if the binary suport bps_max and they friends. Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com>
2014-10-29 12:16:01 +00:00
{ "drive", "throttling.bps-total-max", QEMU_CAPS_DRIVE_IOTUNE_MAX},
libvirt: qemu: enable/disable protected key management ops Introduces two new -machine option parameters to the QEMU command to enable/disable the CPACF protected key management operations for a guest: aes-key-wrap='on|off' dea-key-wrap='on|off' The QEMU code maps the corresponding domain configuration elements to the QEMU -machine option parameters to create the QEMU command: <cipher name='aes' state='on'> --> aes-key-wrap=on <cipher name='aes' state='off'> --> aes-key-wrap=off <cipher name='dea' state='on'> --> dea-key-wrap=on <cipher name='dea' state='off'> --> dea-key-wrap=off Signed-off-by: Tony Krowiak <akrowiak@linux.vnet.ibm.com> Signed-off-by: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-04-27 21:57:29 +00:00
{ "machine", "aes-key-wrap", QEMU_CAPS_AES_KEY_WRAP },
{ "machine", "dea-key-wrap", QEMU_CAPS_DEA_KEY_WRAP },
qemu: Process new 'append' attribute for char dev with output to a file By default, QEMU truncates serial file on open. Sometimes, it could be weird - for example, when we are trying to investigate some event, which occured several restarts ago. This patch adds an ability to preserve previous content. Signed-off-by: Dmitry Mishin <dim@virtuozzo.com>
2015-12-24 14:27:55 +00:00
{ "chardev", "append", QEMU_CAPS_CHARDEV_FILE_APPEND },
qemu: add spice opengl support Add Spice graphics gl attribute. qemu 2.6 should have -spice gl=on argument to enable opengl rendering context (patches on the ML). This is necessary to actually enable virgl rendering. Add a qemuxml2argv test for virtio-gpu + spice with virgl. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-02-19 14:30:15 +00:00
{ "spice", "gl", QEMU_CAPS_SPICE_GL },
qemu: add support for logging chardev output to a file Honour the <log file='...'/> element in chardevs to output data to a file. This requires QEMU >= 2.6 Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-02-23 11:56:34 +00:00
{ "chardev", "logfile", QEMU_CAPS_CHARDEV_LOGFILE },
qemu: check for debug-threads capability QEMU (somewhere around 2.0) added a new sub-option to the -name flag -name debug-threads=on. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-03-10 19:46:38 +00:00
{ "name", "debug-threads", QEMU_CAPS_NAME_DEBUG_THREADS },
qemu: command: Use -name guest= if available -name guest= is the explicit parameter for passing a VM name. Using it is required to allow a VM with an '=' in the name https://bugzilla.redhat.com/show_bug.cgi?id=1276485
2016-04-22 22:39:09 +00:00
{ "name", "guest", QEMU_CAPS_NAME_GUEST },
qemu_capabilites: add QEMU_CAPS_SPICE_UNIX Add a new capability to detect support of unix sockets for spice graphics. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-06-07 22:21:29 +00:00
{ "spice", "unix", QEMU_CAPS_SPICE_UNIX },
caps: Add new capability for the bps/iops throttling length Add the capability to detect if the qemu binary can support the feature to use bps-max-length and friends.
2016-09-19 10:47:19 +00:00
{ "drive", "throttling.bps-total-max-length", QEMU_CAPS_DRIVE_IOTUNE_MAX_LENGTH },
caps: Add new capability for the iotune group name Add the capability to detect if the qemu binary can support the feature to use throttling.group.
2016-11-07 11:19:50 +00:00
{ "drive", "throttling.group", QEMU_CAPS_DRIVE_IOTUNE_GROUP },
qemu: add rendernode argument Add a new attribute 'rendernode' to <gl> spice element. Give it to QEMU if qemu supports it (queued for 2.9). Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-02-14 21:04:13 +00:00
{ "spice", "rendernode", QEMU_CAPS_SPICE_RENDERNODE },
qemu: format kernel_irqchip on the command line Add kernel_irqchip=split/on to the QEMU command line and a capability that looks for it in query-command-line-options output. For the 'split' option, use a version check since it cannot be reasonably probed. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-03-17 07:26:49 +00:00
{ "machine", "kernel_irqchip", QEMU_CAPS_MACHINE_KERNEL_IRQCHIP },
qemu: Introduce a new QEMU capability for -machine loadparm Add new capability for the "-machine loadparm" QEMU option. Add the capabilities replies/xml for s390x for QEMU 2.9.50. Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
2017-06-01 16:36:26 +00:00
{ "machine", "loadparm", QEMU_CAPS_LOADPARM },
qemu: capabilities: introduce QEMU_CAPS_VNC_MULTI_SERVERS Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-07-21 16:44:14 +00:00
{ "vnc", "vnc", QEMU_CAPS_VNC_MULTI_SERVERS },
qemu: introduce QEMU_CAPS_CHARDEV_RECONNECT Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-08-09 13:06:40 +00:00
{ "chardev", "reconnect", QEMU_CAPS_CHARDEV_RECONNECT },
Reintroduce QEMU_CAPS_SECCOMP_SANDBOX Commit 766d5c1b deprecated the capability, because we were assuming it for every QEMU binary. At the time of the introduction, there was no way to probe for this via QMP. However since QEMU 1.5.0 (which is the earliest version we support) we can rely on the query-command-line-options command to detect this feature. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-18 12:46:54 +00:00
{ "sandbox", "enable", QEMU_CAPS_SECCOMP_SANDBOX },
Introduce QEMU_CAPS_SECCOMP_BLACKLIST QEMU commit 1bd6152 changed the default behavior from whitelist to blacklist and introduced a few sets of system calls. Use the 'elevateprivileges' parameter of -sandbox as a witness of this change. https://bugzilla.redhat.com/show_bug.cgi?id=1492597 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-31 20:15:02 +00:00
{ "sandbox", "elevateprivileges", QEMU_CAPS_SECCOMP_BLACKLIST },
qemu: probe for -chardev 'fd' parameter for FD passing QEMU >= 2.12 will support passing of pre-opened file descriptors for socket based character devices. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-14 10:34:37 +00:00
{ "chardev", "fd", QEMU_CAPS_CHARDEV_FD_PASS },
qemu: detect -machine mem-merge capability * src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d813; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
2013-05-14 05:25:49 +00:00
};
static int
virQEMUCapsProbeQMPCommandLine(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
qemu: allow qmp probing for cmdline options without params That can be lately achieved with by having .param == NULL in the virQEMUCapsCommandLineProps struct. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-06-17 11:41:16 +00:00
bool found = false;
qemu: detect -machine mem-merge capability * src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d813; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
2013-05-14 05:25:49 +00:00
int nvalues;
char **values;
size_t i, j;
for (i = 0; i < ARRAY_CARDINALITY(virQEMUCapsCommandLine); i++) {
if ((nvalues = qemuMonitorGetCommandLineOptionParameters(mon,
virQEMUCapsCommandLine[i].option,
qemu: allow qmp probing for cmdline options without params That can be lately achieved with by having .param == NULL in the virQEMUCapsCommandLineProps struct. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-06-17 11:41:16 +00:00
&values,
&found)) < 0)
qemu: detect -machine mem-merge capability * src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d813; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
2013-05-14 05:25:49 +00:00
return -1;
qemu: allow qmp probing for cmdline options without params That can be lately achieved with by having .param == NULL in the virQEMUCapsCommandLineProps struct. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-06-17 11:41:16 +00:00
if (found && !virQEMUCapsCommandLine[i].param)
virQEMUCapsSet(qemuCaps, virQEMUCapsCommandLine[i].flag);
qemu: detect -machine mem-merge capability * src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d813; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
2013-05-14 05:25:49 +00:00
for (j = 0; j < nvalues; j++) {
qemu: allow qmp probing for cmdline options without params That can be lately achieved with by having .param == NULL in the virQEMUCapsCommandLineProps struct. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-06-17 11:41:16 +00:00
if (STREQ_NULLABLE(virQEMUCapsCommandLine[i].param, values[j])) {
qemu: detect -machine mem-merge capability * src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d813; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
2013-05-14 05:25:49 +00:00
virQEMUCapsSet(qemuCaps, virQEMUCapsCommandLine[i].flag);
break;
}
}
virstring: Unify string list function names We have couple of functions that operate over NULL terminated lits of strings. However, our naming sucks: virStringJoin virStringFreeList virStringFreeListCount virStringArrayHasString virStringGetFirstWithPrefix We can do better: virStringListJoin virStringListFree virStringListFreeCount virStringListHasString virStringListGetFirstWithPrefix Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-11-25 08:18:35 +00:00
virStringListFree(values);
qemu: detect -machine mem-merge capability * src/qemu/qemu_capabilities.h: New capability bit. * src/qemu/qemu_capabilities.c (virQEMUCapsProbeQMPCommandLine): New function, based on qemuMonitorGetCommandLineOptionParameters, which was introduced by commit bd56d0d813; use it to set new capability bit. (virQEMUCapsInitQMP): Use new function.
2013-05-14 05:25:49 +00:00
}
return 0;
}
Make non-KVM machines work with QMP probing When there is no 'qemu-kvm' binary and the emulator used for a machine is, for example, 'qemu-system-x86_64' that, by default, runs without kvm enabled, libvirt still supplies '-no-kvm' option to this process, even though it does not recognize such option (making the start of a domain fail in that case). This patch fixes building a command-line for QEMU machines without KVM acceleration and is based on following assumptions: - QEMU_CAPS_KVM flag means that QEMU is running KVM accelerated machines by default (without explicitly requesting that using a command-line option). It is the closest to the truth according to the code with the only exception being the comment next to the flag, so it's fixed in this patch as well. - QEMU_CAPS_ENABLE_KVM flag means that QEMU is, by default, running without KVM acceleration and in case we need KVM acceleration it needs to be explicitly instructed to do so. This is partially true for the past (this option essentially means that QEMU recognizes the '-enable-kvm' option, even though it's almost the same).
2012-10-31 07:31:49 +00:00
qemu: Add RDMA migration capabilities
2014-09-11 12:11:54 +00:00
static int
virQEMUCapsProbeQMPMigrationCapabilities(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
char **caps = NULL;
int ncaps;
if ((ncaps = qemuMonitorGetMigrationCapabilities(mon, &caps)) < 0)
return -1;
virQEMUCapsProcessStringFlags(qemuCaps,
ARRAY_CARDINALITY(virQEMUCapsMigration),
virQEMUCapsMigration,
ncaps, caps);
qemu: Drop virQEMUCapsFreeStringList The implementation matches virStringListFreeCount. The only difference between the two functions is the ordering of their parameters. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-03 20:31:26 +00:00
virStringListFreeCount(caps, ncaps);
qemu: Add RDMA migration capabilities
2014-09-11 12:11:54 +00:00
return 0;
}
qemu: Probe GIC capabilities QEMU introduced the query-gic-capabilities QMP command with commit 4468d4e0f383: use the command, if available, to probe available GIC capabilities. The information obtained is stored in a virQEMUCaps instance, and will be later used to fill in a virDomainCaps instance.
2016-03-08 17:24:18 +00:00
/**
* virQEMUCapsProbeQMPGICCapabilities:
* @qemuCaps: QEMU binary capabilities
* @mon: QEMU monitor
*
* Use @mon to obtain information about the GIC capabilities for the
* corresponding QEMU binary, and store them in @qemuCaps.
*
* Returns: 0 on success, <0 on failure
*/
static int
virQEMUCapsProbeQMPGICCapabilities(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
virGICCapability *caps = NULL;
int ncaps;
if ((ncaps = qemuMonitorGetGICCapabilities(mon, &caps)) < 0)
return -1;
qemu: Add virQEMUCapsSetGICCapabilities() For use in the test suite.
2016-05-10 08:50:34 +00:00
virQEMUCapsSetGICCapabilities(qemuCaps, caps, ncaps);
qemu: Probe GIC capabilities QEMU introduced the query-gic-capabilities QMP command with commit 4468d4e0f383: use the command, if available, to probe available GIC capabilities. The information obtained is stored in a virQEMUCaps instance, and will be later used to fill in a virDomainCaps instance.
2016-03-08 17:24:18 +00:00
return 0;
}
Move command/event capabilities detection out of QEMU monitor code The qemuMonitorSetCapabilities() API is used to initialize the QMP protocol capabilities. It has since been abused to initialize some libvirt internal capabilities based on command/event existance too. Move the latter code out into qemuCapsProbeQMP() in the QEMU capabilities source file instead Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-13 14:54:02 +00:00
qemu: Fix probing of AMD SEV support So the procedure to detect SEV support works like this: 1) we detect that sev-guest is among the QOM types and set the cap flag 2) we probe the monitor for SEV support - this is tricky, because QEMU with compiled SEV support will always report -object sev-guest and query-sev-capabilities command, that however doesn't mean SEV is supported 3) depending on what the monitor returned, we either keep or clear the capability flag for SEV Commit a349c6c21c6 added an explicit check for "GenericError" in the monitor reply to prevent libvirtd to spam logs about missing 'query-sev-capabilities' command. At the same time though, it returned success in this case which means that we didn't clear the capability flag afterwards and happily formatted SEV into qemuCaps. Therefore, adjust all the relevant callers to handle -1 on errors, 0 on SEV being unsupported and 1 on SEV being supported. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-14 13:54:46 +00:00
/* Returns -1 on error, 0 if SEV is not supported, 1 if SEV is supported */
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
static int
virQEMUCapsProbeQMPSEVCapabilities(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
qemu: Fix probing of AMD SEV support So the procedure to detect SEV support works like this: 1) we detect that sev-guest is among the QOM types and set the cap flag 2) we probe the monitor for SEV support - this is tricky, because QEMU with compiled SEV support will always report -object sev-guest and query-sev-capabilities command, that however doesn't mean SEV is supported 3) depending on what the monitor returned, we either keep or clear the capability flag for SEV Commit a349c6c21c6 added an explicit check for "GenericError" in the monitor reply to prevent libvirtd to spam logs about missing 'query-sev-capabilities' command. At the same time though, it returned success in this case which means that we didn't clear the capability flag afterwards and happily formatted SEV into qemuCaps. Therefore, adjust all the relevant callers to handle -1 on errors, 0 on SEV being unsupported and 1 on SEV being supported. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-14 13:54:46 +00:00
int rc = -1;
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
virSEVCapability *caps = NULL;
qemu: Fix probing of AMD SEV support So the procedure to detect SEV support works like this: 1) we detect that sev-guest is among the QOM types and set the cap flag 2) we probe the monitor for SEV support - this is tricky, because QEMU with compiled SEV support will always report -object sev-guest and query-sev-capabilities command, that however doesn't mean SEV is supported 3) depending on what the monitor returned, we either keep or clear the capability flag for SEV Commit a349c6c21c6 added an explicit check for "GenericError" in the monitor reply to prevent libvirtd to spam logs about missing 'query-sev-capabilities' command. At the same time though, it returned success in this case which means that we didn't clear the capability flag afterwards and happily formatted SEV into qemuCaps. Therefore, adjust all the relevant callers to handle -1 on errors, 0 on SEV being unsupported and 1 on SEV being supported. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-14 13:54:46 +00:00
if ((rc = qemuMonitorGetSEVCapabilities(mon, &caps)) <= 0)
return rc;
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
remove virQEMUCapsSetSEVCapabilities It is only used in one place. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-06-12 11:38:29 +00:00
virSEVCapabilitiesFree(qemuCaps->sevCapabilities);
qemuCaps->sevCapabilities = caps;
qemu: Fix probing of AMD SEV support So the procedure to detect SEV support works like this: 1) we detect that sev-guest is among the QOM types and set the cap flag 2) we probe the monitor for SEV support - this is tricky, because QEMU with compiled SEV support will always report -object sev-guest and query-sev-capabilities command, that however doesn't mean SEV is supported 3) depending on what the monitor returned, we either keep or clear the capability flag for SEV Commit a349c6c21c6 added an explicit check for "GenericError" in the monitor reply to prevent libvirtd to spam logs about missing 'query-sev-capabilities' command. At the same time though, it returned success in this case which means that we didn't clear the capability flag afterwards and happily formatted SEV into qemuCaps. Therefore, adjust all the relevant callers to handle -1 on errors, 0 on SEV being unsupported and 1 on SEV being supported. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-14 13:54:46 +00:00
return rc;
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
}
qemu: Publish virQEMUCapsCPUFilterFeatures Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-13 15:28:13 +00:00
bool
Move CMT feature filtering to QEMU driver It really doesn't belong to the generic CPU driver. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-07-21 15:02:37 +00:00
virQEMUCapsCPUFilterFeatures(const char *name,
qemu: Skip virQEMUCapsCPUFilterFeatures on non-x86 CPUs All features the function is currently supposed to filter out are specific to x86_64. We should avoid removing them on other architectures. It seems to be quite unlikely other achitectures would use the same names, but one can never be sure. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-18 13:05:26 +00:00
void *opaque)
Move CMT feature filtering to QEMU driver It really doesn't belong to the generic CPU driver. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-07-21 15:02:37 +00:00
{
qemu: Pass virArch * to virQEMUCapsCPUFilterFeatures The filter only needs to know the CPU architecture. Passing virQEMUCapsPtr as opaque is a bit overkill. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-13 15:26:07 +00:00
virArch *arch = opaque;
qemu: Skip virQEMUCapsCPUFilterFeatures on non-x86 CPUs All features the function is currently supposed to filter out are specific to x86_64. We should avoid removing them on other architectures. It seems to be quite unlikely other achitectures would use the same names, but one can never be sure. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-18 13:05:26 +00:00
qemu: Pass virArch * to virQEMUCapsCPUFilterFeatures The filter only needs to know the CPU architecture. Passing virQEMUCapsPtr as opaque is a bit overkill. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-13 15:26:07 +00:00
if (!ARCH_IS_X86(*arch))
qemu: Skip virQEMUCapsCPUFilterFeatures on non-x86 CPUs All features the function is currently supposed to filter out are specific to x86_64. We should avoid removing them on other architectures. It seems to be quite unlikely other achitectures would use the same names, but one can never be sure. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-18 13:05:26 +00:00
return true;
Move CMT feature filtering to QEMU driver It really doesn't belong to the generic CPU driver. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-07-21 15:02:37 +00:00
if (STREQ(name, "cmt") ||
STREQ(name, "mbm_total") ||
STREQ(name, "mbm_local"))
return false;
return true;
}
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
/**
* Returns 0 when host CPU model provided by QEMU was filled in qemuCaps,
* 1 when the caller should fall back to using virCapsPtr->host.cpu,
qemu-capabilities: Adjust function header comments of virQEMUCapsInitCPUModel* Adjust function descriptions of virQEMUCapsInitCPUModelS390 and virQEMUCapsInitCPUModel to the changes introduced with commitID 74fc32a955. Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-27 12:12:17 +00:00
* 2 when cpu model info is not supported for this configuration,
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
* -1 on error.
*/
static int
virQEMUCapsInitCPUModelS390(virQEMUCapsPtr qemuCaps,
s390: qemu-capabilities: Avoid error message when missing non-kvm host cpu info Libvirt prints an error on startup when it is missing host cpu model information for any queried qemu binary. On s390 we only have host cpu model information for kvm enabled qemu instances. So when virt type is not kvm, this is actually not an error on s390. This patch adds virt type as a parameter to virQEMUCapsInitCPUModelS390, and a new return code 2 for virQEMUCapsInitCPUModel and virQEMUCapsInitCPUModelS390. If the virt type is not kvm then we skip printing the scary error message and return 2 because this case is actually expected behavior. The new return code is meant to differentiate between the failure case and the case where we simply expect the cpu model information to be unattainable. Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-24 08:02:02 +00:00
virDomainVirtType type,
qemu: Move common code in virQEMUCapsInitCPUModel one layer up Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-30 11:50:44 +00:00
qemuMonitorCPUModelInfoPtr modelInfo,
qemu: Add migratable parameter to virQEMUCapsInitCPUModel The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:33:50 +00:00
virCPUDefPtr cpu,
bool migratable)
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
{
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
size_t i;
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
if (!modelInfo) {
s390: qemu-capabilities: Avoid error message when missing non-kvm host cpu info Libvirt prints an error on startup when it is missing host cpu model information for any queried qemu binary. On s390 we only have host cpu model information for kvm enabled qemu instances. So when virt type is not kvm, this is actually not an error on s390. This patch adds virt type as a parameter to virQEMUCapsInitCPUModelS390, and a new return code 2 for virQEMUCapsInitCPUModel and virQEMUCapsInitCPUModelS390. If the virt type is not kvm then we skip printing the scary error message and return 2 because this case is actually expected behavior. The new return code is meant to differentiate between the failure case and the case where we simply expect the cpu model information to be unattainable. Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-24 08:02:02 +00:00
if (type == VIR_DOMAIN_VIRT_KVM) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("missing host CPU model info from QEMU "
"capabilities for binary %s"),
qemuCaps->binary);
return -1;
}
return 2;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
}
qemu: Fix crash in qemucapsprobe The qemucapsprobe helper calls virQEMUCapsNewForBinaryInternal with caps == NULL, causing the following crash: Program received signal SIGSEGV, Segmentation fault. #0 0x00007ffff788775f in virQEMUCapsInitHostCPUModel (qemuCaps=qemuCaps@entry=0x649680, host=host@entry=0x10) at src/qemu/qemu_capabilities.c:2969 #1 0x00007ffff7889dbf in virQEMUCapsNewForBinaryInternal (caps=caps@entry=0x0, binary=<optimized out>, libDir=libDir@entry=0x4033f6 "/tmp", cacheDir=cacheDir@entry=0x0, runUid=runUid@entry=4294967295, runGid=runGid@entry=4294967295, qmpOnly=true) at src/qemu/qemu_capabilities.c:4039 #2 0x0000000000401702 in main (argc=2, argv=0x7fffffffd968) at tests/qemucapsprobe.c:73 Caused by v2.2.0-182-g68c7011. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-27 11:39:51 +00:00
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
if (VIR_STRDUP(cpu->model, modelInfo->name) < 0 ||
VIR_ALLOC_N(cpu->features, modelInfo->nprops) < 0)
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
return -1;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
cpu->nfeatures_max = modelInfo->nprops;
cpu->nfeatures = 0;
for (i = 0; i < modelInfo->nprops; i++) {
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
virCPUFeatureDefPtr feature = cpu->features + cpu->nfeatures;
qemuMonitorCPUPropertyPtr prop = modelInfo->props + i;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
if (prop->type != QEMU_MONITOR_CPU_PROPERTY_BOOLEAN)
continue;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
if (VIR_STRDUP(feature->name, prop->name) < 0)
return -1;
qemu: Add migratable parameter to virQEMUCapsInitCPUModel The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:33:50 +00:00
if (!prop->value.boolean ||
(migratable && prop->migratable == VIR_TRISTATE_BOOL_NO))
feature->policy = VIR_CPU_FEATURE_DISABLE;
else
feature->policy = VIR_CPU_FEATURE_REQUIRE;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
cpu->nfeatures++;
}
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
return 0;
}
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
/**
* Returns 0 when host CPU model provided by QEMU was filled in qemuCaps,
* 1 when the caller should fall back to using virCapsPtr->host.cpu,
* -1 on error.
*/
static int
virQEMUCapsInitCPUModelX86(virQEMUCapsPtr qemuCaps,
virDomainVirtType type,
qemu: Move common code in virQEMUCapsInitCPUModel one layer up Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-30 11:50:44 +00:00
qemuMonitorCPUModelInfoPtr model,
qemu: Add migratable parameter to virQEMUCapsInitCPUModel The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:33:50 +00:00
virCPUDefPtr cpu,
bool migratable)
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
{
virCPUDataPtr data = NULL;
unsigned long long sigFamily = 0;
unsigned long long sigModel = 0;
qemu: Parse CPU stepping from query-cpu-model-expansion Even though only family and model are used for matching CPUID data with CPU models from cpu_map.xml, stepping is used by x86DataFilterTSX which is supposed to disable TSX on CPU models with broken TSX support. Thus we need to start parsing stepping from QEMU to make sure we don't disable TSX on CPUs which provide working TSX implementation. See the following patch for a real world example of such CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-10 11:34:28 +00:00
unsigned long long sigStepping = 0;
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
int ret = -1;
size_t i;
if (!model)
return 1;
if (!(data = virCPUDataNew(VIR_ARCH_X86_64)))
goto cleanup;
for (i = 0; i < model->nprops; i++) {
qemuMonitorCPUPropertyPtr prop = model->props + i;
switch (prop->type) {
case QEMU_MONITOR_CPU_PROPERTY_BOOLEAN:
qemu: Add migratable parameter to virQEMUCapsInitCPUModel The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:33:50 +00:00
if (!prop->value.boolean ||
(migratable && prop->migratable == VIR_TRISTATE_BOOL_NO))
continue;
if (virCPUx86DataAddFeature(data, prop->name) < 0)
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
goto cleanup;
qemu: Add migratable parameter to virQEMUCapsInitCPUModel The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:33:50 +00:00
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
break;
case QEMU_MONITOR_CPU_PROPERTY_STRING:
if (STREQ(prop->name, "vendor") &&
virCPUx86DataSetVendor(data, prop->value.string) < 0)
goto cleanup;
break;
case QEMU_MONITOR_CPU_PROPERTY_NUMBER:
if (STREQ(prop->name, "family"))
sigFamily = prop->value.number;
else if (STREQ(prop->name, "model"))
sigModel = prop->value.number;
qemu: Parse CPU stepping from query-cpu-model-expansion Even though only family and model are used for matching CPUID data with CPU models from cpu_map.xml, stepping is used by x86DataFilterTSX which is supposed to disable TSX on CPU models with broken TSX support. Thus we need to start parsing stepping from QEMU to make sure we don't disable TSX on CPUs which provide working TSX implementation. See the following patch for a real world example of such CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-10 11:34:28 +00:00
else if (STREQ(prop->name, "stepping"))
sigStepping = prop->value.number;
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
break;
case QEMU_MONITOR_CPU_PROPERTY_LAST:
break;
}
}
qemu: Parse CPU stepping from query-cpu-model-expansion Even though only family and model are used for matching CPUID data with CPU models from cpu_map.xml, stepping is used by x86DataFilterTSX which is supposed to disable TSX on CPU models with broken TSX support. Thus we need to start parsing stepping from QEMU to make sure we don't disable TSX on CPUs which provide working TSX implementation. See the following patch for a real world example of such CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-10 11:34:28 +00:00
if (virCPUx86DataSetSignature(data, sigFamily, sigModel, sigStepping) < 0)
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
goto cleanup;
cpu: Drop unused parameter from cpuDecode The "preferred" parameter is not used by any caller of cpuDecode anymore. It's only used internally in cpu_x86 to implement cpuBaseline. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-26 08:24:05 +00:00
if (cpuDecode(cpu, data, virQEMUCapsGetCPUDefinitions(qemuCaps, type)) < 0)
qemu: Get host CPU model from QEMU on x86_64 Until now host-model CPU mode tried to enable all CPU features supported by the host CPU even if QEMU/KVM did not support them. This caused a number of issues and made host-model quite unreliable. Asking QEMU for the CPU it can provide and the current host makes host-model much more robust. This commit fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1018251 https://bugzilla.redhat.com/show_bug.cgi?id=1371617 https://bugzilla.redhat.com/show_bug.cgi?id=1372581 https://bugzilla.redhat.com/show_bug.cgi?id=1404627 https://bugzilla.redhat.com/show_bug.cgi?id=870071 In addition to that, the following bug should be mostly limited to cases when an unsupported feature is explicitly requested: https://bugzilla.redhat.com/show_bug.cgi?id=1335534 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-11 13:36:34 +00:00
goto cleanup;
ret = 0;
cleanup:
virCPUDataFree(data);
return ret;
}
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
/**
* Returns 0 when host CPU model provided by QEMU was filled in qemuCaps,
qemu-capabilities: Adjust function header comments of virQEMUCapsInitCPUModel* Adjust function descriptions of virQEMUCapsInitCPUModelS390 and virQEMUCapsInitCPUModel to the changes introduced with commitID 74fc32a955. Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-27 12:12:17 +00:00
* 1 when the caller should fall back to other methods,
* 2 when cpu model info is not supported for this configuration,
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
* -1 on error.
*/
qemu: Make virQEMUCapsInitCPUModel testable Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 13:31:23 +00:00
int
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
virQEMUCapsInitCPUModel(virQEMUCapsPtr qemuCaps,
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
virDomainVirtType type,
qemu: Add migratable parameter to virQEMUCapsInitCPUModel The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:33:50 +00:00
virCPUDefPtr cpu,
bool migratable)
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
{
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type);
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
int ret = 1;
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
if (migratable && cpuData->info && !cpuData->info->migratability)
qemu: Add migratable parameter to virQEMUCapsInitCPUModel The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:33:50 +00:00
return 1;
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
if (ARCH_IS_S390(qemuCaps->arch)) {
s390: qemu-capabilities: Avoid error message when missing non-kvm host cpu info Libvirt prints an error on startup when it is missing host cpu model information for any queried qemu binary. On s390 we only have host cpu model information for kvm enabled qemu instances. So when virt type is not kvm, this is actually not an error on s390. This patch adds virt type as a parameter to virQEMUCapsInitCPUModelS390, and a new return code 2 for virQEMUCapsInitCPUModel and virQEMUCapsInitCPUModelS390. If the virt type is not kvm then we skip printing the scary error message and return 2 because this case is actually expected behavior. The new return code is meant to differentiate between the failure case and the case where we simply expect the cpu model information to be unattainable. Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-24 08:02:02 +00:00
ret = virQEMUCapsInitCPUModelS390(qemuCaps, type, cpuData->info,
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
cpu, migratable);
} else if (ARCH_IS_X86(qemuCaps->arch)) {
ret = virQEMUCapsInitCPUModelX86(qemuCaps, type, cpuData->info,
cpu, migratable);
}
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
qemu: Fix CPU model fallback in domain capabilities Our documentation of the domain capabilities XML says that the fallback attribute of a CPU model is used to indicate whether the CPU model was detected by libvirt itself (fallback="allow") or by asking the hypervisor (fallback="forbid"). We need to properly set fallback="forbid" when CPU model comes from QEMU to match the documentation. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 20:07:23 +00:00
if (ret == 0)
cpu->fallback = VIR_CPU_FALLBACK_FORBID;
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
return ret;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
}
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
static virCPUDefPtr
virQEMUCapsNewHostCPUModel(void)
{
virCPUDefPtr cpu;
if (VIR_ALLOC(cpu) < 0)
return NULL;
cpu->type = VIR_CPU_TYPE_GUEST;
cpu->mode = VIR_CPU_MODE_CUSTOM;
cpu->match = VIR_CPU_MATCH_EXACT;
cpu->fallback = VIR_CPU_FALLBACK_ALLOW;
return cpu;
}
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
void
virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
virArch hostArch,
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
virDomainVirtType type)
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
{
virCPUDefPtr cpu = NULL;
qemu: cpu: fix "full" CPU to include all "reported" CPU features On Core i5 650 x86_64 kvm guest fail to start with error [1] for next cpu config: <cpu mode='host-model' check='partial'> <model fallback='allow'/> <feature policy='require' name='x2apic'/> </cpu> The problem is in full CPU calculation in virQEMUCapsInitHostCPUModel. It is supposed to include features emulated by qemu and missed on host. Some of such features may be not included however. For Core i5 650 host CPU is detected as Westmere and reported CPU as SandyBridge. x2apic is missed on host and provided by installed qemu. The feature is not mentioned in reported CPU features explicitly because SandyBridge model include it. As a result full CPU does not include x2apic too. Solution is to expand guest cpu features before updating fullCPU features. [1] error: the CPU is incompatible with host CPU: \ Host CPU does not provide required features: x2apic Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2018-04-11 08:57:32 +00:00
virCPUDefPtr cpuExpanded = NULL;
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
virCPUDefPtr migCPU = NULL;
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
virCPUDefPtr hostCPU = NULL;
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
virCPUDefPtr fullCPU = NULL;
size_t i;
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
int rc;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
if (!virQEMUCapsGuestIsNative(hostArch, qemuCaps->arch))
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
return;
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
if (!(cpu = virQEMUCapsNewHostCPUModel()))
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
goto error;
qemu: Add migratable parameter to virQEMUCapsInitCPUModel The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:33:50 +00:00
if ((rc = virQEMUCapsInitCPUModel(qemuCaps, type, cpu, false)) < 0) {
qemu: Refactor virQEMUCapsInitHostCPUModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-10 18:16:24 +00:00
goto error;
} else if (rc == 1) {
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
VIR_DEBUG("No host CPU model info from QEMU; probing host CPU directly");
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
hostCPU = virQEMUCapsProbeHostCPUForEmulator(hostArch, qemuCaps, type);
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
if (!hostCPU ||
virCPUDefCopyModelFilter(cpu, hostCPU, true,
qemu: Skip virQEMUCapsCPUFilterFeatures on non-x86 CPUs All features the function is currently supposed to filter out are specific to x86_64. We should avoid removing them on other architectures. It seems to be quite unlikely other achitectures would use the same names, but one can never be sure. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-18 13:05:26 +00:00
virQEMUCapsCPUFilterFeatures,
qemu: Pass virArch * to virQEMUCapsCPUFilterFeatures The filter only needs to know the CPU architecture. Passing virQEMUCapsPtr as opaque is a bit overkill. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-13 15:26:07 +00:00
&qemuCaps->arch) < 0)
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
goto error;
s390: qemu-capabilities: Avoid error message when missing non-kvm host cpu info Libvirt prints an error on startup when it is missing host cpu model information for any queried qemu binary. On s390 we only have host cpu model information for kvm enabled qemu instances. So when virt type is not kvm, this is actually not an error on s390. This patch adds virt type as a parameter to virQEMUCapsInitCPUModelS390, and a new return code 2 for virQEMUCapsInitCPUModel and virQEMUCapsInitCPUModelS390. If the virt type is not kvm then we skip printing the scary error message and return 2 because this case is actually expected behavior. The new return code is meant to differentiate between the failure case and the case where we simply expect the cpu model information to be unattainable. Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-24 08:02:02 +00:00
} else if (rc == 2) {
VIR_DEBUG("QEMU does not provide CPU model for arch=%s virttype=%s",
virArchToString(qemuCaps->arch),
virDomainVirtTypeToString(type));
goto error;
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
} else if (type == VIR_DOMAIN_VIRT_KVM &&
virCPUGetHostIsSupported(qemuCaps->arch)) {
if (!(fullCPU = virCPUGetHost(qemuCaps->arch, VIR_CPU_TYPE_GUEST,
cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs All APIs which expect a list of CPU models supported by hypervisors were switched from char **models and int models to just accept a pointer to virDomainCapsCPUModels object stored in domain capabilities. This avoids the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated list of model names and also allows the various cpu driver APIs to access additional details (such as its usability) about each CPU model. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-22 13:51:33 +00:00
NULL, NULL)))
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
goto error;
qemu: cpu: fix "full" CPU to include all "reported" CPU features On Core i5 650 x86_64 kvm guest fail to start with error [1] for next cpu config: <cpu mode='host-model' check='partial'> <model fallback='allow'/> <feature policy='require' name='x2apic'/> </cpu> The problem is in full CPU calculation in virQEMUCapsInitHostCPUModel. It is supposed to include features emulated by qemu and missed on host. Some of such features may be not included however. For Core i5 650 host CPU is detected as Westmere and reported CPU as SandyBridge. x2apic is missed on host and provided by installed qemu. The feature is not mentioned in reported CPU features explicitly because SandyBridge model include it. As a result full CPU does not include x2apic too. Solution is to expand guest cpu features before updating fullCPU features. [1] error: the CPU is incompatible with host CPU: \ Host CPU does not provide required features: x2apic Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2018-04-11 08:57:32 +00:00
if (!(cpuExpanded = virCPUDefCopy(cpu)) ||
virCPUExpandFeatures(qemuCaps->arch, cpuExpanded) < 0)
goto error;
for (i = 0; i < cpuExpanded->nfeatures; i++) {
if (cpuExpanded->features[i].policy == VIR_CPU_FEATURE_REQUIRE &&
virCPUDefUpdateFeature(fullCPU, cpuExpanded->features[i].name,
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
VIR_CPU_FEATURE_REQUIRE) < 0)
goto error;
}
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
}
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
if (!(migCPU = virQEMUCapsNewHostCPUModel()))
goto error;
if ((rc = virQEMUCapsInitCPUModel(qemuCaps, type, migCPU, true)) < 0) {
goto error;
} else if (rc == 1) {
VIR_DEBUG("CPU migratability not provided by QEMU");
virCPUDefFree(migCPU);
if (!(migCPU = virCPUCopyMigratable(qemuCaps->arch, cpu)))
goto error;
}
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
virQEMUCapsSetHostModel(qemuCaps, type, cpu, migCPU, fullCPU);
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
cleanup:
qemu: cpu: fix "full" CPU to include all "reported" CPU features On Core i5 650 x86_64 kvm guest fail to start with error [1] for next cpu config: <cpu mode='host-model' check='partial'> <model fallback='allow'/> <feature policy='require' name='x2apic'/> </cpu> The problem is in full CPU calculation in virQEMUCapsInitHostCPUModel. It is supposed to include features emulated by qemu and missed on host. Some of such features may be not included however. For Core i5 650 host CPU is detected as Westmere and reported CPU as SandyBridge. x2apic is missed on host and provided by installed qemu. The feature is not mentioned in reported CPU features explicitly because SandyBridge model include it. As a result full CPU does not include x2apic too. Solution is to expand guest cpu features before updating fullCPU features. [1] error: the CPU is incompatible with host CPU: \ Host CPU does not provide required features: x2apic Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2018-04-11 08:57:32 +00:00
virCPUDefFree(cpuExpanded);
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
virCPUDefFree(hostCPU);
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
return;
error:
virCPUDefFree(cpu);
qemu: Pass migratable host CPU model to virCPUUpdate We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 13:31:17 +00:00
virCPUDefFree(migCPU);
qemu: Use more data for comparing CPUs With QEMU older than 2.9.0 libvirt uses CPUID instruction to determine what CPU features are supported on the host. This was later used when checking compatibility of guest CPUs. Since QEMU 2.9.0 we ask QEMU for the host CPU data. But the two methods we use usually provide disjoint sets of CPU features because QEMU/KVM does not support all features provided by the host CPU and on the other hand it can enable some feature even if the host CPU does not support them. So if there is a domain which requires a CPU features disabled by QEMU/KVM, libvirt will refuse to start it with QEMU > 2.9.0 as its guest CPU is incompatible with the host CPU data we got from QEMU. But such domain would happily start on older QEMU (of course, the features would be missing the guest CPU). To fix this regression, we need to combine both CPU feature sets when checking guest CPU compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1439933 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 18:46:05 +00:00
virCPUDefFree(fullCPU);
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
virResetLastError();
qemu: Report better host-model CPUs in domain caps One of the main reasons for introducing host-model CPU definition in a domain capabilities XML was the inability to express disabled features in a host capabilities XML. That is, when a host CPU is, e.g., Haswell without x2apic support, host capabilities XML will have to report it as Westmere + a bunch of additional features., but we really want to use Haswell - x2apic when creating a host-model CPU. Unfortunately, I somehow forgot to do the last step and the code would just copy the CPU definition found in the host capabilities XML. This changed recently for new QEMU versions which allow us to query host CPU, but any slightly older QEMU will not benefit from any change I did. This patch makes sure the right CPU model is filled in the domain capabilities even with old QEMU. The issue was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1426456 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-08 12:32:46 +00:00
goto cleanup;
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
}
qemu: Make virQEMUCapsInitCPUModel testable Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 13:31:23 +00:00
void
virQEMUCapsSetCPUModelInfo(virQEMUCapsPtr qemuCaps,
virDomainVirtType type,
qemuMonitorCPUModelInfoPtr modelInfo)
{
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type);
cpuData->info = modelInfo;
qemu: Make virQEMUCapsInitCPUModel testable Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 13:31:23 +00:00
}
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
static int
virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
xmlXPathContextPtr ctxt,
virDomainVirtType virtType)
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
{
char *str = NULL;
xmlNodePtr hostCPUNode;
qemu: Rename hostCPU/feature element in capabilities cache The element will be generalized in the following commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 15:30:13 +00:00
xmlNodePtr *nodes = NULL;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
xmlNodePtr oldnode = ctxt->node;
qemuMonitorCPUModelInfoPtr hostCPU = NULL;
int ret = -1;
size_t i;
int n;
qemuMonitorCPUModelInfo: Add support for non-migratable features QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:33:08 +00:00
int val;
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
if (virtType == VIR_DOMAIN_VIRT_KVM)
hostCPUNode = virXPathNode("./hostCPU[@type='kvm']", ctxt);
else
hostCPUNode = virXPathNode("./hostCPU[@type='tcg']", ctxt);
if (!hostCPUNode) {
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
ret = 0;
goto cleanup;
}
if (VIR_ALLOC(hostCPU) < 0)
goto cleanup;
if (!(hostCPU->name = virXMLPropString(hostCPUNode, "model"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing host CPU model name in QEMU "
"capabilities cache"));
goto cleanup;
}
qemuMonitorCPUModelInfo: Add support for non-migratable features QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:33:08 +00:00
if (!(str = virXMLPropString(hostCPUNode, "migratability")) ||
(val = virTristateBoolTypeFromString(str)) <= 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("invalid migratability value for host CPU model"));
goto cleanup;
}
hostCPU->migratability = val == VIR_TRISTATE_BOOL_YES;
VIR_FREE(str);
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
ctxt->node = hostCPUNode;
qemu: Rename hostCPU/feature element in capabilities cache The element will be generalized in the following commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 15:30:13 +00:00
if ((n = virXPathNodeSet("./property", ctxt, &nodes)) > 0) {
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
if (VIR_ALLOC_N(hostCPU->props, n) < 0)
goto cleanup;
hostCPU->nprops = n;
for (i = 0; i < n; i++) {
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
qemuMonitorCPUPropertyPtr prop = hostCPU->props + i;
ctxt->node = nodes[i];
if (!(prop->name = virXMLPropString(ctxt->node, "name"))) {
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing 'name' attribute for a host CPU"
qemu: Rename hostCPU/feature element in capabilities cache The element will be generalized in the following commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 15:30:13 +00:00
" model property in QEMU capabilities cache"));
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
goto cleanup;
}
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
if (!(str = virXMLPropString(ctxt->node, "type")) ||
qemuMonitorCPUModelInfo: Add support for non-migratable features QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:33:08 +00:00
(val = qemuMonitorCPUPropertyTypeFromString(str)) < 0) {
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
_("missing or invalid CPU model property type "
"in QEMU capabilities cache"));
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
goto cleanup;
}
VIR_FREE(str);
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
qemuMonitorCPUModelInfo: Add support for non-migratable features QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:33:08 +00:00
prop->type = val;
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
switch (prop->type) {
case QEMU_MONITOR_CPU_PROPERTY_BOOLEAN:
if (virXPathBoolean("./@value='true'", ctxt))
prop->value.boolean = true;
break;
case QEMU_MONITOR_CPU_PROPERTY_STRING:
prop->value.string = virXMLPropString(ctxt->node, "value");
if (!prop->value.string) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("invalid string value for '%s' host CPU "
"model property in QEMU capabilities cache"),
prop->name);
goto cleanup;
}
break;
case QEMU_MONITOR_CPU_PROPERTY_NUMBER:
if (virXPathLongLong("string(./@value)", ctxt,
&prop->value.number) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("invalid number value for '%s' host CPU "
"model property in QEMU capabilities cache"),
prop->name);
goto cleanup;
}
break;
case QEMU_MONITOR_CPU_PROPERTY_LAST:
break;
}
qemuMonitorCPUModelInfo: Add support for non-migratable features QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:33:08 +00:00
if ((str = virXMLPropString(ctxt->node, "migratable"))) {
if ((val = virTristateBoolTypeFromString(str)) <= 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("unknown migratable value for '%s' host "
"CPU model property"),
prop->name);
goto cleanup;
}
prop->migratable = val;
VIR_FREE(str);
}
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
}
}
qemu: Make virQEMUCapsInitCPUModel testable Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 13:31:23 +00:00
virQEMUCapsSetCPUModelInfo(qemuCaps, virtType, hostCPU);
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
hostCPU = NULL;
ret = 0;
cleanup:
ctxt->node = oldnode;
VIR_FREE(str);
qemu: Rename hostCPU/feature element in capabilities cache The element will be generalized in the following commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 15:30:13 +00:00
VIR_FREE(nodes);
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
qemuMonitorCPUModelInfoFree(hostCPU);
return ret;
}
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
static int
virQEMUCapsLoadCPUModels(virQEMUCapsPtr qemuCaps,
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
xmlXPathContextPtr ctxt,
virDomainVirtType type)
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
{
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virDomainCapsCPUModelsPtr cpus = NULL;
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
xmlNodePtr *nodes = NULL;
char *str = NULL;
size_t i;
int n;
int ret = -1;
qemu: Store CPU usability blockers in caps cache Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-21 14:11:14 +00:00
xmlNodePtr node;
xmlNodePtr *blockerNodes = NULL;
char **blockers = NULL;
int nblockers;
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (type == VIR_DOMAIN_VIRT_KVM)
n = virXPathNodeSet("./cpu[@type='kvm']", ctxt, &nodes);
else
n = virXPathNodeSet("./cpu[@type='tcg']", ctxt, &nodes);
if (n < 0) {
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("failed to parse qemu capabilities cpus"));
goto cleanup;
}
if (n == 0) {
ret = 0;
goto cleanup;
}
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (!(cpus = virDomainCapsCPUModelsNew(n)))
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
goto cleanup;
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (type == VIR_DOMAIN_VIRT_KVM)
qemuCaps->kvmCPUModels = cpus;
else
qemuCaps->tcgCPUModels = cpus;
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
for (i = 0; i < n; i++) {
qemu: Add support for unavailable-features QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the CPU model can be used without modifications. We can use unavailable-features for providing CPU model usability info in domain capabilities XML: <domainCapabilities> ... <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'> <model fallback='allow'>Skylake-Client</model> ... </mode> <mode name='custom' supported='yes'> <model usable='yes'>qemu64</model> <model usable='yes'>qemu32</model> <model usable='no'>phenom</model> <model usable='yes'>pentium3</model> <model usable='yes'>pentium2</model> <model usable='yes'>pentium</model> <model usable='yes'>n270</model> <model usable='yes'>kvm64</model> <model usable='yes'>kvm32</model> <model usable='yes'>coreduo</model> <model usable='yes'>core2duo</model> <model usable='no'>athlon</model> <model usable='yes'>Westmere</model> <model usable='yes'>Skylake-Client</model> ... </mode> </cpu> ... </domainCapabilities> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 11:08:12 +00:00
int usable = VIR_DOMCAPS_CPU_USABLE_UNKNOWN;
if ((str = virXMLPropString(nodes[i], "usable")) &&
(usable = virDomainCapsCPUUsableTypeFromString(str)) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("unknown value '%s' in attribute 'usable'"), str);
goto cleanup;
}
VIR_FREE(str);
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
if (!(str = virXMLPropString(nodes[i], "name"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing cpu name in QEMU capabilities cache"));
goto cleanup;
}
qemu: Store CPU usability blockers in caps cache Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-21 14:11:14 +00:00
node = ctxt->node;
ctxt->node = nodes[i];
nblockers = virXPathNodeSet("./blocker", ctxt, &blockerNodes);
ctxt->node = node;
if (nblockers < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("failed to parse CPU blockers in QEMU capabilities"));
goto cleanup;
}
if (nblockers > 0) {
size_t j;
if (VIR_ALLOC_N(blockers, nblockers + 1) < 0)
goto cleanup;
for (j = 0; j < nblockers; j++) {
if (!(blockers[j] = virXMLPropString(blockerNodes[j], "name"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing blocker name in QEMU "
"capabilities cache"));
goto cleanup;
}
}
qemu: Fix memory leak in virQEMUCapsLoadCPUModels Don't leak @blockNodes in the loop. ==226576== 7,120 bytes in 60 blocks are definitely lost in loss record 122 of 125 ==226576== at 0x4835214: calloc (vg_replace_malloc.c:711) ==226576== by 0x4950D7B: virAllocN (viralloc.c:191) ==226576== by 0x49EB5BB: virXPathNodeSet (virxml.c:676) ==226576== by 0x104DB67: virQEMUCapsLoadCPUModels (qemu_capabilities.c:3738) ==226576== by 0x105510D: virQEMUCapsLoadCache (qemu_capabilities.c:3929) ==226576== by 0x104459F: qemuTestParseCapabilities (testutilsqemu.c:498) ==226576== by 0x1040DC9: testQemuCapsCopy (qemucapabilitiestest.c:105) ==226576== by 0x1041F07: virTestRun (testutils.c:180) ==226576== by 0x1040B45: mymain (qemucapabilitiestest.c:181) ==226576== by 0x104320F: virTestMain (testutils.c:1119) ==226576== by 0x1041149: main (qemucapabilitiestest.c:193) Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-10-27 07:53:03 +00:00
VIR_FREE(blockerNodes);
qemu: Store CPU usability blockers in caps cache Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-21 14:11:14 +00:00
}
if (virDomainCapsCPUModelsAddSteal(cpus, &str, usable, &blockers) < 0)
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
goto cleanup;
}
ret = 0;
cleanup:
VIR_FREE(nodes);
VIR_FREE(str);
qemu: Store CPU usability blockers in caps cache Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-21 14:11:14 +00:00
VIR_FREE(blockerNodes);
virStringListFree(blockers);
qemu: Introduce virQEMUCapsLoadCPUModels This patch moves the CPU models parsing code from virQEMUCapsLoadCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:19 +00:00
return ret;
}
qemu: privatize _virQEMUCapsCachePriv struct Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:02:40 +00:00
struct _virQEMUCapsCachePriv {
char *libDir;
uid_t runUid;
gid_t runGid;
virArch hostArch;
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
unsigned int microcodeVersion;
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
char *kernelVersion;
qemu: privatize _virQEMUCapsCachePriv struct Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:02:40 +00:00
};
typedef struct _virQEMUCapsCachePriv virQEMUCapsCachePriv;
typedef virQEMUCapsCachePriv *virQEMUCapsCachePrivPtr;
qemu: introduce struct _virQEMUCapsCachePriv This will store private data that will be used by following patches when switching to virFileCache. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-20 14:17:23 +00:00
static void
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsCachePrivFree(void *privData)
qemu: introduce struct _virQEMUCapsCachePriv This will store private data that will be used by following patches when switching to virFileCache. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-20 14:17:23 +00:00
{
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsCachePrivPtr priv = privData;
qemu: introduce struct _virQEMUCapsCachePriv This will store private data that will be used by following patches when switching to virFileCache. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-20 14:17:23 +00:00
VIR_FREE(priv->libDir);
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
VIR_FREE(priv->kernelVersion);
qemu: introduce struct _virQEMUCapsCachePriv This will store private data that will be used by following patches when switching to virFileCache. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-20 14:17:23 +00:00
VIR_FREE(priv);
}
qemu: caps: Format SEV platform data into qemuCaps cache Since we're not saving the platform-specific data into a cache, we're not going to populate the structure, which in turn will cause a crash upon calling virNodeGetSEVInfo because of a NULL pointer dereference. Ultimately, we should start caching this data along with host-specific capabilities like NUMA and SELinux stuff into a separate cache, but for the time being, this is a semi-proper fix for a potential crash. Backtrace (requires libvirtd restart to load qemu caps from cache): #0 qemuGetSEVInfoToParams #1 qemuNodeGetSEVInfo #2 virNodeGetSEVInfo #3 remoteDispatchNodeGetSevInfo #4 remoteDispatchNodeGetSevInfoHelper #5 virNetServerProgramDispatchCall #6 virNetServerProgramDispatch #7 virNetServerProcessMsg #8 virNetServerHandleJob #9 virThreadPoolWorker #10 virThreadHelper https: //bugzilla.redhat.com/show_bug.cgi?id=1612009 Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2018-08-09 13:27:26 +00:00
static int
virQEMUCapsParseSEVInfo(virQEMUCapsPtr qemuCaps, xmlXPathContextPtr ctxt)
{
VIR_AUTOPTR(virSEVCapability) sev = NULL;
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_GUEST))
return 0;
if (virXPathBoolean("boolean(./sev)", ctxt) == 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing SEV platform data in QEMU "
"capabilities cache"));
return -1;
}
if (VIR_ALLOC(sev) < 0)
return -1;
if (virXPathUInt("string(./sev/cbitpos)", ctxt, &sev->cbitpos) < 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing or malformed SEV cbitpos information "
"in QEMU capabilities cache"));
return -1;
}
if (virXPathUInt("string(./sev/reducedPhysBits)", ctxt,
&sev->reduced_phys_bits) < 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing or malformed SEV reducedPhysBits information "
"in QEMU capabilities cache"));
return -1;
}
if (!(sev->pdh = virXPathString("string(./sev/pdh)", ctxt))) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing SEV pdh information "
"in QEMU capabilities cache"));
return -1;
}
if (!(sev->cert_chain = virXPathString("string(./sev/certChain)", ctxt))) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing SEV certChain information "
"in QEMU capabilities cache"));
return -1;
}
VIR_STEAL_PTR(qemuCaps->sevCapabilities, sev);
return 0;
}
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
/*
* Parsing a doc that looks like
*
* <qemuCaps>
* <qemuctime>234235253</qemuctime>
* <selfctime>234235253</selfctime>
qemu: Add libvirt version check to refresh capabilities algorithm Rather than an algorithm based solely on libvirtd ctime to refresh the capabilities add the element of the libvirt build version into the equation. Since that version wouldn't be there prior to this code being run - don't fail on reading the capabilities if not found. In this case, the cache will always be rebuilt when a new libvirt version is installed.
2015-05-23 14:19:20 +00:00
* <selfvers>1002016</selfvers>
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
* <usedQMP/>
* <flag name='foo'/>
* <flag name='bar'/>
* ...
* <cpu name="pentium3"/>
* ...
qemu: record the QEMU default machine in capabilities We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 12:18:27 +00:00
* <machine name="pc-1.0" alias="pc" hotplugCpus='yes' maxCpus="4" default="yes"/>
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
* ...
* </qemuCaps>
*/
qemu: Export caps cache APIs for tests Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-28 13:01:02 +00:00
int
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
virQEMUCapsLoadCache(virArch hostArch,
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
virQEMUCapsPtr qemuCaps,
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
const char *filename)
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
{
xmlDocPtr doc = NULL;
int ret = -1;
size_t i;
int n;
xmlNodePtr *nodes = NULL;
xmlXPathContextPtr ctxt = NULL;
Fix virQEMUCapsLoadCache leaks Valgrind reported leaking of maxCpus and arch strings from virXPathString, as well as the leak of the machineMaxCpus array. Don't use 'str' for the strings we don't want to free, to allow freeing of 'str' in the cleanup label and free machineMaxCpus in virCapsReset too.
2014-03-19 16:13:19 +00:00
char *str = NULL;
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
long long int l;
qemu: Add libvirt version check to refresh capabilities algorithm Rather than an algorithm based solely on libvirtd ctime to refresh the capabilities add the element of the libvirt build version into the equation. Since that version wouldn't be there prior to this code being run - don't fail on reading the capabilities if not found. In this case, the cache will always be rebuilt when a new libvirt version is installed.
2015-05-23 14:19:20 +00:00
unsigned long lu;
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
if (!(doc = virXMLParseFile(filename)))
goto cleanup;
if (!(ctxt = xmlXPathNewContext(doc))) {
virReportOOMError();
goto cleanup;
}
ctxt->node = xmlDocGetRootElement(doc);
if (STRNEQ((const char *)ctxt->node->name, "qemuCaps")) {
virReportError(VIR_ERR_XML_ERROR,
_("unexpected root element <%s>, "
"expecting <qemuCaps>"),
ctxt->node->name);
goto cleanup;
}
if (virXPathLongLong("string(./qemuctime)", ctxt, &l) < 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing qemuctime in QEMU capabilities XML"));
goto cleanup;
}
qemu: Store loaded QEMU binary ctime in qemuCaps virQEMUCapsLoadCache loads QEMU capabilities from a file, but strangely enough it returns the loaded QEMU binary ctime in qemuctime parameter instead of storing it in qemuCaps. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-10-27 08:54:13 +00:00
qemuCaps->ctime = (time_t)l;
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
if (virXPathLongLong("string(./selfctime)", ctxt, &l) < 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing selfctime in QEMU capabilities XML"));
goto cleanup;
}
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
qemuCaps->libvirtCtime = (time_t)l;
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
qemuCaps->libvirtVersion = 0;
qemu: Add libvirt version check to refresh capabilities algorithm Rather than an algorithm based solely on libvirtd ctime to refresh the capabilities add the element of the libvirt build version into the equation. Since that version wouldn't be there prior to this code being run - don't fail on reading the capabilities if not found. In this case, the cache will always be rebuilt when a new libvirt version is installed.
2015-05-23 14:19:20 +00:00
if (virXPathULong("string(./selfvers)", ctxt, &lu) == 0)
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
qemuCaps->libvirtVersion = lu;
qemu: Add libvirt version check to refresh capabilities algorithm Rather than an algorithm based solely on libvirtd ctime to refresh the capabilities add the element of the libvirt build version into the equation. Since that version wouldn't be there prior to this code being run - don't fail on reading the capabilities if not found. In this case, the cache will always be rebuilt when a new libvirt version is installed.
2015-05-23 14:19:20 +00:00
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemuCaps->usedQMP = virXPathBoolean("count(./usedQMP) > 0",
ctxt) > 0;
if ((n = virXPathNodeSet("./flag", ctxt, &nodes)) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("failed to parse qemu capabilities flags"));
goto cleanup;
}
VIR_DEBUG("Got flags %d", n);
Miscellaneous for-loop syntax clean-ups Checking whether x > 0 before looping over [0..x] items doesn't make sense and multi-line body must have curly brackets around it. Best viewed with '-w'. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-02-22 10:04:38 +00:00
for (i = 0; i < n; i++) {
int flag;
if (!(str = virXMLPropString(nodes[i], "name"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing flag name in QEMU capabilities cache"));
goto cleanup;
}
flag = virQEMUCapsTypeFromString(str);
if (flag < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Unknown qemu capabilities flag %s"), str);
goto cleanup;
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
}
Miscellaneous for-loop syntax clean-ups Checking whether x > 0 before looping over [0..x] items doesn't make sense and multi-line body must have curly brackets around it. Best viewed with '-w'. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-02-22 10:04:38 +00:00
VIR_FREE(str);
virQEMUCapsSet(qemuCaps, flag);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
}
VIR_FREE(nodes);
if (virXPathUInt("string(./version)", ctxt, &qemuCaps->version) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing version in QEMU capabilities cache"));
goto cleanup;
}
if (virXPathUInt("string(./kvmVersion)", ctxt, &qemuCaps->kvmVersion) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing version in QEMU capabilities cache"));
goto cleanup;
}
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
if (virXPathUInt("string(./microcodeVersion)", ctxt,
&qemuCaps->microcodeVersion) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing microcode version in QEMU capabilities cache"));
goto cleanup;
}
qemu: Add tests for virQEMUCapsNewCopy Doing a load, copy, format cycle on all QEMU capabilities XML files should make sure we don't forget to update virQEMUCapsNewCopy when adding new elements to QEMU capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-04 20:43:22 +00:00
if (virXPathBoolean("boolean(./package)", ctxt) > 0) {
qemuCaps->package = virXPathString("string(./package)", ctxt);
if (!qemuCaps->package &&
VIR_STRDUP(qemuCaps->package, "") < 0)
goto cleanup;
}
qemu: include libvirt & QEMU versions in QEMU log files It is often helpful to know which version of libvirt and QEMU was present when a guest was first launched. Ensure this info is written into the QEMU log file for each guest.
2015-02-02 10:28:30 +00:00
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
if (virXPathBoolean("boolean(./kernelVersion)", ctxt) > 0) {
qemuCaps->kernelVersion = virXPathString("string(./kernelVersion)", ctxt);
if (!qemuCaps->kernelVersion)
goto cleanup;
}
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
if (!(str = virXPathString("string(./arch)", ctxt))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing arch in QEMU capabilities cache"));
goto cleanup;
}
if (!(qemuCaps->arch = virArchFromString(str))) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("unknown arch %s in QEMU capabilities cache"), str);
goto cleanup;
}
Fix virQEMUCapsLoadCache leaks Valgrind reported leaking of maxCpus and arch strings from virXPathString, as well as the leak of the machineMaxCpus array. Don't use 'str' for the strings we don't want to free, to allow freeing of 'str' in the cleanup label and free machineMaxCpus in virCapsReset too.
2014-03-19 16:13:19 +00:00
VIR_FREE(str);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
if (virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0 ||
virQEMUCapsLoadHostCPUModelInfo(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) < 0)
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
goto cleanup;
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0 ||
virQEMUCapsLoadCPUModels(qemuCaps, ctxt, VIR_DOMAIN_VIRT_QEMU) < 0)
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
goto cleanup;
if ((n = virXPathNodeSet("./machine", ctxt, &nodes)) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("failed to parse qemu capabilities machines"));
goto cleanup;
}
if (n > 0) {
qemuCaps->nmachineTypes = n;
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (VIR_ALLOC_N(qemuCaps->machineTypes, qemuCaps->nmachineTypes) < 0)
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
goto cleanup;
for (i = 0; i < n; i++) {
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (!(qemuCaps->machineTypes[i].name = virXMLPropString(nodes[i], "name"))) {
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing machine name in QEMU capabilities cache"));
goto cleanup;
}
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
qemuCaps->machineTypes[i].alias = virXMLPropString(nodes[i], "alias");
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
str = virXMLPropString(nodes[i], "maxCpus");
if (str &&
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
virStrToLong_ui(str, NULL, 10, &(qemuCaps->machineTypes[i].maxCpus)) < 0) {
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("malformed machine cpu count in QEMU capabilities cache"));
goto cleanup;
}
Fix virQEMUCapsLoadCache leaks Valgrind reported leaking of maxCpus and arch strings from virXPathString, as well as the leak of the machineMaxCpus array. Don't use 'str' for the strings we don't want to free, to allow freeing of 'str' in the cleanup label and free machineMaxCpus in virCapsReset too.
2014-03-19 16:13:19 +00:00
VIR_FREE(str);
qemu: capabilities: Extract availability of new cpu hotplug for machine types QEMU reports whether 'query-hotpluggable-cpus' is supported for a given machine type. Extract and cache the information using the capability cache. When copying the capabilities for a new start of qemu, mask out the presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type doesn't support hotpluggable cpus.
2016-07-29 07:45:19 +00:00
str = virXMLPropString(nodes[i], "hotplugCpus");
if (STREQ_NULLABLE(str, "yes"))
qemuCaps->machineTypes[i].hotplugCpus = true;
VIR_FREE(str);
qemu: record the QEMU default machine in capabilities We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 12:18:27 +00:00
str = virXMLPropString(nodes[i], "default");
if (STREQ_NULLABLE(str, "yes"))
qemuCaps->machineTypes[i].qemuDefault = true;
VIR_FREE(str);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
}
}
VIR_FREE(nodes);
qemu: Cache GIC capabilities Implement support for saving GIC capabilities in the cache and read them back.
2016-03-10 16:59:51 +00:00
if ((n = virXPathNodeSet("./gic", ctxt, &nodes)) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("failed to parse qemu capabilities gic"));
goto cleanup;
}
if (n > 0) {
unsigned int uintValue;
bool boolValue;
qemuCaps->ngicCapabilities = n;
if (VIR_ALLOC_N(qemuCaps->gicCapabilities, n) < 0)
goto cleanup;
for (i = 0; i < n; i++) {
virGICCapabilityPtr cap = &qemuCaps->gicCapabilities[i];
if (!(str = virXMLPropString(nodes[i], "version"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing GIC version "
"in QEMU capabilities cache"));
goto cleanup;
}
if (virStrToLong_ui(str, NULL, 10, &uintValue) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("malformed GIC version "
"in QEMU capabilities cache"));
goto cleanup;
}
cap->version = uintValue;
VIR_FREE(str);
if (!(str = virXMLPropString(nodes[i], "kernel"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing in-kernel GIC information "
"in QEMU capabilities cache"));
goto cleanup;
}
if (!(boolValue = STREQ(str, "yes")) && STRNEQ(str, "no")) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("malformed in-kernel GIC information "
"in QEMU capabilities cache"));
goto cleanup;
}
if (boolValue)
cap->implementation |= VIR_GIC_IMPLEMENTATION_KERNEL;
VIR_FREE(str);
if (!(str = virXMLPropString(nodes[i], "emulated"))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing emulated GIC information "
"in QEMU capabilities cache"));
goto cleanup;
}
if (!(boolValue = STREQ(str, "yes")) && STRNEQ(str, "no")) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("malformed emulated GIC information "
"in QEMU capabilities cache"));
goto cleanup;
}
if (boolValue)
cap->implementation |= VIR_GIC_IMPLEMENTATION_EMULATED;
VIR_FREE(str);
}
}
VIR_FREE(nodes);
qemu: caps: Format SEV platform data into qemuCaps cache Since we're not saving the platform-specific data into a cache, we're not going to populate the structure, which in turn will cause a crash upon calling virNodeGetSEVInfo because of a NULL pointer dereference. Ultimately, we should start caching this data along with host-specific capabilities like NUMA and SELinux stuff into a separate cache, but for the time being, this is a semi-proper fix for a potential crash. Backtrace (requires libvirtd restart to load qemu caps from cache): #0 qemuGetSEVInfoToParams #1 qemuNodeGetSEVInfo #2 virNodeGetSEVInfo #3 remoteDispatchNodeGetSevInfo #4 remoteDispatchNodeGetSevInfoHelper #5 virNetServerProgramDispatchCall #6 virNetServerProgramDispatch #7 virNetServerProcessMsg #8 virNetServerHandleJob #9 virThreadPoolWorker #10 virThreadHelper https: //bugzilla.redhat.com/show_bug.cgi?id=1612009 Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2018-08-09 13:27:26 +00:00
if (virQEMUCapsParseSEVInfo(qemuCaps, ctxt) < 0)
goto cleanup;
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_QEMU);
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
ret = 0;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
cleanup:
Fix virQEMUCapsLoadCache leaks Valgrind reported leaking of maxCpus and arch strings from virXPathString, as well as the leak of the machineMaxCpus array. Don't use 'str' for the strings we don't want to free, to allow freeing of 'str' in the cleanup label and free machineMaxCpus in virCapsReset too.
2014-03-19 16:13:19 +00:00
VIR_FREE(str);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
VIR_FREE(nodes);
xmlXPathFreeContext(ctxt);
xmlFreeDoc(doc);
return ret;
}
qemu: Introduce virQEMUCapsFormatHostCPUModelInfo The CPU model info formating code in virQEMUCapsFormatCache will get more complicated soon. Separating the code in virQEMUCapsFormatHostCPUModelInfo will make the result easier to read. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-13 17:42:57 +00:00
static void
virQEMUCapsFormatHostCPUModelInfo(virQEMUCapsPtr qemuCaps,
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
virBufferPtr buf,
virDomainVirtType type)
qemu: Introduce virQEMUCapsFormatHostCPUModelInfo The CPU model info formating code in virQEMUCapsFormatCache will get more complicated soon. Separating the code in virQEMUCapsFormatHostCPUModelInfo will make the result easier to read. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-13 17:42:57 +00:00
{
qemu: Move qemuCaps host CPU data in a struct We need to store several CPU related data structure for both KVM and TCG. So instead of keeping two different copies of everything let's make a virQEMUCapsHostCPUData struct and use it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-07 16:15:26 +00:00
virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type);
qemuMonitorCPUModelInfoPtr model = cpuData->info;
const char *typeStr = type == VIR_DOMAIN_VIRT_KVM ? "kvm" : "tcg";
qemu: Introduce virQEMUCapsFormatHostCPUModelInfo The CPU model info formating code in virQEMUCapsFormatCache will get more complicated soon. Separating the code in virQEMUCapsFormatHostCPUModelInfo will make the result easier to read. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-13 17:42:57 +00:00
size_t i;
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
if (!model)
return;
qemuMonitorCPUModelInfo: Add support for non-migratable features QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:33:08 +00:00
virBufferAsprintf(buf,
"<hostCPU type='%s' model='%s' migratability='%s'>\n",
typeStr, model->name,
model->migratability ? "yes" : "no");
qemu: Introduce virQEMUCapsFormatHostCPUModelInfo The CPU model info formating code in virQEMUCapsFormatCache will get more complicated soon. Separating the code in virQEMUCapsFormatHostCPUModelInfo will make the result easier to read. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-13 17:42:57 +00:00
virBufferAdjustIndent(buf, 2);
for (i = 0; i < model->nprops; i++) {
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
qemuMonitorCPUPropertyPtr prop = model->props + i;
virBufferAsprintf(buf, "<property name='%s' type='%s' ",
prop->name,
qemuMonitorCPUPropertyTypeToString(prop->type));
switch (prop->type) {
case QEMU_MONITOR_CPU_PROPERTY_BOOLEAN:
virBufferAsprintf(buf, "value='%s'",
prop->value.boolean ? "true" : "false");
break;
case QEMU_MONITOR_CPU_PROPERTY_STRING:
virBufferEscapeString(buf, "value='%s'", prop->value.string);
break;
case QEMU_MONITOR_CPU_PROPERTY_NUMBER:
virBufferAsprintf(buf, "value='%lld'", prop->value.number);
break;
case QEMU_MONITOR_CPU_PROPERTY_LAST:
break;
}
qemuMonitorCPUModelInfo: Add support for non-migratable features QEMU is able to tell us whether a CPU feature would block migration or not. This patch adds support for storing such features in qemuMonitorCPUModelInfo. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 08:33:08 +00:00
if (prop->migratable > 0)
virBufferAsprintf(buf, " migratable='%s'",
virTristateBoolTypeToString(prop->migratable));
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:01:30 +00:00
virBufferAddLit(buf, "/>\n");
qemu: Introduce virQEMUCapsFormatHostCPUModelInfo The CPU model info formating code in virQEMUCapsFormatCache will get more complicated soon. Separating the code in virQEMUCapsFormatHostCPUModelInfo will make the result easier to read. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-13 17:42:57 +00:00
}
virBufferAdjustIndent(buf, -2);
virBufferAddLit(buf, "</hostCPU>\n");
}
qemu: Introduce virQEMUCapsFormatCPUModels This patch moves the CPU models formatting code from virQEMUCapsFormatCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:31 +00:00
static void
virQEMUCapsFormatCPUModels(virQEMUCapsPtr qemuCaps,
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virBufferPtr buf,
virDomainVirtType type)
qemu: Introduce virQEMUCapsFormatCPUModels This patch moves the CPU models formatting code from virQEMUCapsFormatCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:31 +00:00
{
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virDomainCapsCPUModelsPtr cpus;
const char *typeStr;
qemu: Introduce virQEMUCapsFormatCPUModels This patch moves the CPU models formatting code from virQEMUCapsFormatCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:31 +00:00
size_t i;
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (type == VIR_DOMAIN_VIRT_KVM) {
typeStr = "kvm";
cpus = qemuCaps->kvmCPUModels;
} else {
typeStr = "tcg";
cpus = qemuCaps->tcgCPUModels;
}
if (!cpus)
return;
for (i = 0; i < cpus->nmodels; i++) {
qemu: Add support for unavailable-features QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the CPU model can be used without modifications. We can use unavailable-features for providing CPU model usability info in domain capabilities XML: <domainCapabilities> ... <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'> <model fallback='allow'>Skylake-Client</model> ... </mode> <mode name='custom' supported='yes'> <model usable='yes'>qemu64</model> <model usable='yes'>qemu32</model> <model usable='no'>phenom</model> <model usable='yes'>pentium3</model> <model usable='yes'>pentium2</model> <model usable='yes'>pentium</model> <model usable='yes'>n270</model> <model usable='yes'>kvm64</model> <model usable='yes'>kvm32</model> <model usable='yes'>coreduo</model> <model usable='yes'>core2duo</model> <model usable='no'>athlon</model> <model usable='yes'>Westmere</model> <model usable='yes'>Skylake-Client</model> ... </mode> </cpu> ... </domainCapabilities> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 11:08:12 +00:00
virDomainCapsCPUModelPtr cpu = cpus->models + i;
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virBufferAsprintf(buf, "<cpu type='%s' ", typeStr);
qemu: Add support for unavailable-features QEMU 2.8.0 adds support for unavailable-features in query-cpu-definitions reply. The unavailable-features array lists CPU features which prevent a corresponding CPU model from being usable on current host. It can only be used when all the unavailable features are disabled. Empty array means the CPU model can be used without modifications. We can use unavailable-features for providing CPU model usability info in domain capabilities XML: <domainCapabilities> ... <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'> <model fallback='allow'>Skylake-Client</model> ... </mode> <mode name='custom' supported='yes'> <model usable='yes'>qemu64</model> <model usable='yes'>qemu32</model> <model usable='no'>phenom</model> <model usable='yes'>pentium3</model> <model usable='yes'>pentium2</model> <model usable='yes'>pentium</model> <model usable='yes'>n270</model> <model usable='yes'>kvm64</model> <model usable='yes'>kvm32</model> <model usable='yes'>coreduo</model> <model usable='yes'>core2duo</model> <model usable='no'>athlon</model> <model usable='yes'>Westmere</model> <model usable='yes'>Skylake-Client</model> ... </mode> </cpu> ... </domainCapabilities> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-21 11:08:12 +00:00
virBufferEscapeString(buf, "name='%s'", cpu->name);
if (cpu->usable) {
virBufferAsprintf(buf, " usable='%s'",
virDomainCapsCPUUsableTypeToString(cpu->usable));
}
qemu: Store CPU usability blockers in caps cache Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-21 14:11:14 +00:00
if (cpu->blockers) {
size_t j;
virBufferAddLit(buf, ">\n");
virBufferAdjustIndent(buf, 2);
for (j = 0; cpu->blockers[j]; j++)
virBufferAsprintf(buf, "<blocker name='%s'/>\n", cpu->blockers[j]);
virBufferAdjustIndent(buf, -2);
virBufferAddLit(buf, "</cpu>\n");
} else {
virBufferAddLit(buf, "/>\n");
}
qemu: Introduce virQEMUCapsFormatCPUModels This patch moves the CPU models formatting code from virQEMUCapsFormatCache into a separate function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 20:51:31 +00:00
}
}
qemu: caps: Format SEV platform data into qemuCaps cache Since we're not saving the platform-specific data into a cache, we're not going to populate the structure, which in turn will cause a crash upon calling virNodeGetSEVInfo because of a NULL pointer dereference. Ultimately, we should start caching this data along with host-specific capabilities like NUMA and SELinux stuff into a separate cache, but for the time being, this is a semi-proper fix for a potential crash. Backtrace (requires libvirtd restart to load qemu caps from cache): #0 qemuGetSEVInfoToParams #1 qemuNodeGetSEVInfo #2 virNodeGetSEVInfo #3 remoteDispatchNodeGetSevInfo #4 remoteDispatchNodeGetSevInfoHelper #5 virNetServerProgramDispatchCall #6 virNetServerProgramDispatch #7 virNetServerProcessMsg #8 virNetServerHandleJob #9 virThreadPoolWorker #10 virThreadHelper https: //bugzilla.redhat.com/show_bug.cgi?id=1612009 Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2018-08-09 13:27:26 +00:00
static void
virQEMUCapsFormatSEVInfo(virQEMUCapsPtr qemuCaps, virBufferPtr buf)
{
virSEVCapabilityPtr sev = virQEMUCapsGetSEVCapabilities(qemuCaps);
virBufferAddLit(buf, "<sev>\n");
virBufferAdjustIndent(buf, 2);
virBufferAsprintf(buf, "<cbitpos>%u</cbitpos>\n", sev->cbitpos);
virBufferAsprintf(buf, "<reducedPhysBits>%u</reducedPhysBits>\n",
sev->reduced_phys_bits);
virBufferEscapeString(buf, "<pdh>%s</pdh>\n", sev->pdh);
virBufferEscapeString(buf, "<certChain>%s</certChain>\n",
sev->cert_chain);
virBufferAdjustIndent(buf, -2);
virBufferAddLit(buf, "</sev>\n");
}
qemu: Export caps cache APIs for tests Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-28 13:01:02 +00:00
char *
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
virQEMUCapsFormatCache(virQEMUCapsPtr qemuCaps)
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
{
virBuffer buf = VIR_BUFFER_INITIALIZER;
qemu: Separate formatting from saving into caps cache We will need to use the formatter directly for testing QEMU capabilities code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-28 12:59:15 +00:00
char *ret = NULL;
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
size_t i;
virBufferAddLit(&buf, "<qemuCaps>\n");
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAdjustIndent(&buf, 2);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAsprintf(&buf, "<qemuctime>%llu</qemuctime>\n",
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
(long long)qemuCaps->ctime);
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAsprintf(&buf, "<selfctime>%llu</selfctime>\n",
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
(long long)qemuCaps->libvirtCtime);
qemu: Add libvirt version check to refresh capabilities algorithm Rather than an algorithm based solely on libvirtd ctime to refresh the capabilities add the element of the libvirt build version into the equation. Since that version wouldn't be there prior to this code being run - don't fail on reading the capabilities if not found. In this case, the cache will always be rebuilt when a new libvirt version is installed.
2015-05-23 14:19:20 +00:00
virBufferAsprintf(&buf, "<selfvers>%lu</selfvers>\n",
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
(unsigned long)qemuCaps->libvirtVersion);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
if (qemuCaps->usedQMP)
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAddLit(&buf, "<usedQMP/>\n");
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
for (i = 0; i < QEMU_CAPS_LAST; i++) {
if (virQEMUCapsGet(qemuCaps, i)) {
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAsprintf(&buf, "<flag name='%s'/>\n",
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
virQEMUCapsTypeToString(i));
}
}
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAsprintf(&buf, "<version>%d</version>\n",
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemuCaps->version);
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAsprintf(&buf, "<kvmVersion>%d</kvmVersion>\n",
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemuCaps->kvmVersion);
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
virBufferAsprintf(&buf, "<microcodeVersion>%u</microcodeVersion>\n",
qemuCaps->microcodeVersion);
qemu: include libvirt & QEMU versions in QEMU log files It is often helpful to know which version of libvirt and QEMU was present when a guest was first launched. Ensure this info is written into the QEMU log file for each guest.
2015-02-02 10:28:30 +00:00
if (qemuCaps->package)
virBufferAsprintf(&buf, "<package>%s</package>\n",
qemuCaps->package);
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
if (qemuCaps->kernelVersion)
virBufferAsprintf(&buf, "<kernelVersion>%s</kernelVersion>\n",
qemuCaps->kernelVersion);
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAsprintf(&buf, "<arch>%s</arch>\n",
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
virArchToString(qemuCaps->arch));
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsFormatHostCPUModelInfo(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsFormatCPUModels(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferEscapeString(&buf, "<machine name='%s'",
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
qemuCaps->machineTypes[i].name);
if (qemuCaps->machineTypes[i].alias)
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
virBufferEscapeString(&buf, " alias='%s'",
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
qemuCaps->machineTypes[i].alias);
qemu: capabilities: Extract availability of new cpu hotplug for machine types QEMU reports whether 'query-hotpluggable-cpus' is supported for a given machine type. Extract and cache the information using the capability cache. When copying the capabilities for a new start of qemu, mask out the presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type doesn't support hotpluggable cpus.
2016-07-29 07:45:19 +00:00
if (qemuCaps->machineTypes[i].hotplugCpus)
virBufferAddLit(&buf, " hotplugCpus='yes'");
qemu: record the QEMU default machine in capabilities We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 12:18:27 +00:00
virBufferAsprintf(&buf, " maxCpus='%u'",
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
qemuCaps->machineTypes[i].maxCpus);
qemu: record the QEMU default machine in capabilities We don't honour the QEMU default machine type anymore, always using the libvirt chosen default instead. The QEMU argv parser, however, will need to know the exacty QEMU default, so we must record that info. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 12:18:27 +00:00
if (qemuCaps->machineTypes[i].qemuDefault)
virBufferAddLit(&buf, " default='yes'");
virBufferAddLit(&buf, "/>\n");
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
}
qemu: Cache GIC capabilities Implement support for saving GIC capabilities in the cache and read them back.
2016-03-10 16:59:51 +00:00
for (i = 0; i < qemuCaps->ngicCapabilities; i++) {
virGICCapabilityPtr cap;
bool kernel;
bool emulated;
cap = &qemuCaps->gicCapabilities[i];
kernel = (cap->implementation & VIR_GIC_IMPLEMENTATION_KERNEL);
emulated = (cap->implementation & VIR_GIC_IMPLEMENTATION_EMULATED);
virBufferAsprintf(&buf,
"<gic version='%d' kernel='%s' emulated='%s'/>\n",
cap->version,
kernel ? "yes" : "no",
emulated ? "yes" : "no");
}
qemu: caps: Format SEV platform data into qemuCaps cache Since we're not saving the platform-specific data into a cache, we're not going to populate the structure, which in turn will cause a crash upon calling virNodeGetSEVInfo because of a NULL pointer dereference. Ultimately, we should start caching this data along with host-specific capabilities like NUMA and SELinux stuff into a separate cache, but for the time being, this is a semi-proper fix for a potential crash. Backtrace (requires libvirtd restart to load qemu caps from cache): #0 qemuGetSEVInfoToParams #1 qemuNodeGetSEVInfo #2 virNodeGetSEVInfo #3 remoteDispatchNodeGetSevInfo #4 remoteDispatchNodeGetSevInfoHelper #5 virNetServerProgramDispatchCall #6 virNetServerProgramDispatch #7 virNetServerProcessMsg #8 virNetServerHandleJob #9 virThreadPoolWorker #10 virThreadHelper https: //bugzilla.redhat.com/show_bug.cgi?id=1612009 Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2018-08-09 13:27:26 +00:00
if (qemuCaps->sevCapabilities)
virQEMUCapsFormatSEVInfo(qemuCaps, &buf);
qemu: elminate hardcoded indent in capabilities cache XML
2014-03-13 00:35:01 +00:00
virBufferAdjustIndent(&buf, -2);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
virBufferAddLit(&buf, "</qemuCaps>\n");
qemu: Separate formatting from saving into caps cache We will need to use the formatter directly for testing QEMU capabilities code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-28 12:59:15 +00:00
if (virBufferCheckError(&buf) == 0)
ret = virBufferContentAndReset(&buf);
return ret;
}
static int
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsSaveFile(void *data,
const char *filename,
void *privData ATTRIBUTE_UNUSED)
qemu: Separate formatting from saving into caps cache We will need to use the formatter directly for testing QEMU capabilities code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-28 12:59:15 +00:00
{
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsPtr qemuCaps = data;
qemu: Separate formatting from saving into caps cache We will need to use the formatter directly for testing QEMU capabilities code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-28 12:59:15 +00:00
char *xml = NULL;
int ret = -1;
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
xml = virQEMUCapsFormatCache(qemuCaps);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
if (virFileWriteStr(filename, xml, 0600) < 0) {
virReportSystemError(errno,
_("Failed to save '%s' for '%s'"),
filename, qemuCaps->binary);
goto cleanup;
}
VIR_DEBUG("Saved caps '%s' for '%s' with (%lld, %lld)",
filename, qemuCaps->binary,
(long long)qemuCaps->ctime,
qemu: move libvirt ctime and version into _virQEMUCaps struct Cleanups the code a little bit and reduces amount of arguments passed throughout the functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 15:55:45 +00:00
(long long)qemuCaps->libvirtCtime);
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
ret = 0;
cleanup:
VIR_FREE(xml);
return ret;
}
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
static bool
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsIsValid(void *data,
void *privData)
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
{
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsPtr qemuCaps = data;
virQEMUCapsCachePrivPtr priv = privData;
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
bool kvmUsable;
qemu: don't pass qemuctime into virQEMUCapsIsValid It's not required and following patches will change the code. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-22 10:53:26 +00:00
struct stat sb;
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
if (!qemuCaps->binary)
return true;
qemu: move libvirt ctime and version check into virQEMUCapsIsValid Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-22 10:52:35 +00:00
if (qemuCaps->libvirtCtime != virGetSelfLastChanged() ||
qemuCaps->libvirtVersion != LIBVIR_VERSION_NUMBER) {
VIR_DEBUG("Outdated capabilities for '%s': libvirt changed "
"(%lld vs %lld, %lu vs %lu)",
qemuCaps->binary,
(long long)qemuCaps->libvirtCtime,
(long long)virGetSelfLastChanged(),
(unsigned long)qemuCaps->libvirtVersion,
(unsigned long)LIBVIR_VERSION_NUMBER);
return false;
}
qemu: don't pass qemuctime into virQEMUCapsIsValid It's not required and following patches will change the code. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-22 10:53:26 +00:00
if (stat(qemuCaps->binary, &sb) < 0) {
char ebuf[1024];
VIR_DEBUG("Failed to stat QEMU binary '%s': %s",
qemuCaps->binary,
virStrerror(errno, ebuf, sizeof(ebuf)));
return false;
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
}
qemu: don't pass qemuctime into virQEMUCapsIsValid It's not required and following patches will change the code. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-22 10:53:26 +00:00
if (sb.st_ctime != qemuCaps->ctime) {
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
VIR_DEBUG("Outdated capabilities for '%s': QEMU binary changed "
"(%lld vs %lld)",
qemuCaps->binary,
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
(long long)sb.st_ctime, (long long)qemuCaps->ctime);
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
return false;
}
qemu: Avoid probing non-native binaries all the time A side effect of recent changes is that we would always try to regenerate the capabilities cache for non-native QEMU binaries based on /dev/kvm availability, which is of course complete nonsense. Make sure that doesn't happen. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2018-09-17 10:23:43 +00:00
if (!virQEMUCapsGuestIsNative(priv->hostArch, qemuCaps->arch)) {
VIR_DEBUG("Guest arch (%s) is not native to host arch (%s), "
"skipping KVM-related checks",
virArchToString(qemuCaps->arch),
virArchToString(priv->hostArch));
return true;
}
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
kvmUsable = virFileAccessibleAs("/dev/kvm", R_OK | W_OK,
qemu: introduce struct _virQEMUCapsCachePriv This will store private data that will be used by following patches when switching to virFileCache. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-20 14:17:23 +00:00
priv->runUid, priv->runGid) == 0;
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
kvmUsable) {
VIR_DEBUG("KVM was not enabled when probing '%s', "
"but it should be usable now",
qemuCaps->binary);
return false;
}
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
!kvmUsable) {
VIR_DEBUG("KVM was enabled when probing '%s', "
"but it is not available now",
qemuCaps->binary);
return false;
}
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
if (priv->microcodeVersion != qemuCaps->microcodeVersion) {
VIR_DEBUG("Outdated capabilities for '%s': microcode version "
"changed (%u vs %u)",
qemuCaps->binary,
priv->microcodeVersion,
qemuCaps->microcodeVersion);
return false;
}
if (STRNEQ_NULLABLE(priv->kernelVersion, qemuCaps->kernelVersion)) {
VIR_DEBUG("Outdated capabilities for '%s': kernel version changed "
"('%s' vs '%s')",
qemuCaps->binary,
priv->kernelVersion,
qemuCaps->kernelVersion);
return false;
}
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
}
qemu: move virQEMUCapsIsValid before its usage and make it static Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-19 12:03:06 +00:00
return true;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
static void virQEMUCapsMonitorNotify(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
qemu: Avoid using global qemu_driver in event handlers We will have to pass a mock-up of the driver when testing monitor events.
2013-07-25 17:26:15 +00:00
virDomainObjPtr vm ATTRIBUTE_UNUSED,
void *opaque ATTRIBUTE_UNUSED)
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
{
}
static qemuMonitorCallbacks callbacks = {
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
.eofNotify = virQEMUCapsMonitorNotify,
.errorNotify = virQEMUCapsMonitorNotify,
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
};
qemu: Split virQEMUCapsInitArchQMPBasic() Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
2017-03-27 14:42:17 +00:00
/**
* virQEMUCapsInitQMPArch:
* @qemuCaps: QEMU capabilities
* @mon: QEMU monitor
*
* Initialize the architecture for @qemuCaps by asking @mon.
*
* Returns: 0 on success, <0 on failure
qemu: Enable the capability bit for -no-kvm-pit-reinjection on x86 only On architectures not supporting the Intel specific programmable interval timer, like e.g. S390, starting a domain with a clock definition containing a pit timer results in the error "Option no-kvm-pit-reinjection not supported for this target". By moving the capability enablement for -no-kvm-pit-reinjection from the InitQMPBasic section into the x86_64 and i686 only enablement section all other architectures are no longer automatically enabled. In addition architecture related capabilities enablements have refactored into a new architecture bound capabilities initialization function. Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-05-07 11:34:27 +00:00
*/
static int
qemu: Split virQEMUCapsInitArchQMPBasic() Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
2017-03-27 14:42:17 +00:00
virQEMUCapsInitQMPArch(virQEMUCapsPtr qemuCaps,
qemu: Enable the capability bit for -no-kvm-pit-reinjection on x86 only On architectures not supporting the Intel specific programmable interval timer, like e.g. S390, starting a domain with a clock definition containing a pit timer results in the error "Option no-kvm-pit-reinjection not supported for this target". By moving the capability enablement for -no-kvm-pit-reinjection from the InitQMPBasic section into the x86_64 and i686 only enablement section all other architectures are no longer automatically enabled. In addition architecture related capabilities enablements have refactored into a new architecture bound capabilities initialization function. Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-05-07 11:34:27 +00:00
qemuMonitorPtr mon)
{
char *archstr = NULL;
int ret = -1;
if (!(archstr = qemuMonitorGetTargetArch(mon)))
qemu: Split virQEMUCapsInitArchQMPBasic() Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
2017-03-27 14:42:17 +00:00
goto cleanup;
qemu: Enable the capability bit for -no-kvm-pit-reinjection on x86 only On architectures not supporting the Intel specific programmable interval timer, like e.g. S390, starting a domain with a clock definition containing a pit timer results in the error "Option no-kvm-pit-reinjection not supported for this target". By moving the capability enablement for -no-kvm-pit-reinjection from the InitQMPBasic section into the x86_64 and i686 only enablement section all other architectures are no longer automatically enabled. In addition architecture related capabilities enablements have refactored into a new architecture bound capabilities initialization function. Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-05-07 11:34:27 +00:00
if ((qemuCaps->arch = virQEMUCapsArchFromString(archstr)) == VIR_ARCH_NONE) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Unknown QEMU arch %s"), archstr);
goto cleanup;
}
qemu: Split virQEMUCapsInitArchQMPBasic() Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
2017-03-27 14:42:17 +00:00
ret = 0;
cleanup:
VIR_FREE(archstr);
return ret;
}
/**
* virQEMUCapsInitQMPBasicArch:
* @qemuCaps: QEMU capabilities
*
* Initialize @qemuCaps with basic architecture-dependent capabilities.
*/
tests: Initialize basic capabilities properly The capabilities used in test cases should match those used during normal operation for the tests to make any sense. This results in the generated command line for a few test cases (most notably non-x86 test cases that were wrongly assuming they could use -no-acpi) changing.
2017-03-02 18:24:22 +00:00
void
qemu: Split virQEMUCapsInitArchQMPBasic() Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
2017-03-27 14:42:17 +00:00
virQEMUCapsInitQMPBasicArch(virQEMUCapsPtr qemuCaps)
{
qemu: Advertise ACPI support for aarch64 guests So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
2017-03-02 17:57:51 +00:00
/* ACPI only works on x86 and aarch64 */
if (ARCH_IS_X86(qemuCaps->arch) ||
qemuCaps->arch == VIR_ARCH_AARCH64) {
qemu: Enable the capability bit for -no-kvm-pit-reinjection on x86 only On architectures not supporting the Intel specific programmable interval timer, like e.g. S390, starting a domain with a clock definition containing a pit timer results in the error "Option no-kvm-pit-reinjection not supported for this target". By moving the capability enablement for -no-kvm-pit-reinjection from the InitQMPBasic section into the x86_64 and i686 only enablement section all other architectures are no longer automatically enabled. In addition architecture related capabilities enablements have refactored into a new architecture bound capabilities initialization function. Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-05-07 11:34:27 +00:00
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
qemu: Advertise ACPI support for aarch64 guests So far, libvirt has assumed that only x86 supports ACPI, but that's inaccurate since aarch64 supports it too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509
2017-03-02 17:57:51 +00:00
}
Deprecate QEMU_CAPS_NO_KVM_PIT The -no-kvm-pit-reinjection option has been deprecated since its introduction in QEMU 1.3. See commit <1569fa1>. Drop the capability since all the QEMUs we support allow tuning the kvm-pit properties via -global. Also add the QEMU_CAPS_KVM_PIT_TICK_POLICY to the clock-catchup tests, since expecting it to succeed with QEMU that does not have kvm-pit makes no sense. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-03 08:38:42 +00:00
/* HPET is x86 specific */
if (ARCH_IS_X86(qemuCaps->arch))
Only set QEMU_CAPS_NO_HPET on x86 QEMU only supports it on x86, but we've been assuming it for all QEMUs when doing QMP capability detection. https://bugzilla.redhat.com/show_bug.cgi?id=1066145
2014-04-17 14:50:43 +00:00
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_HPET);
qemu: Enable the capability bit for -no-kvm-pit-reinjection on x86 only On architectures not supporting the Intel specific programmable interval timer, like e.g. S390, starting a domain with a clock definition containing a pit timer results in the error "Option no-kvm-pit-reinjection not supported for this target". By moving the capability enablement for -no-kvm-pit-reinjection from the InitQMPBasic section into the x86_64 and i686 only enablement section all other architectures are no longer automatically enabled. In addition architecture related capabilities enablements have refactored into a new architecture bound capabilities initialization function. Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2013-05-07 11:34:27 +00:00
}
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
static int
virQEMUCapsProbeQMPSchemaCapabilities(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
struct virQEMUCapsStringFlags *entry;
qemu: monitor: Move processing of QMP schema to the new file The JSON array was processed to the hash table used by the query apis in the monitor code. Move it to a new helper in qemu_qapi.c. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-20 08:29:30 +00:00
virJSONValuePtr schemareply;
virHashTablePtr schema = NULL;
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
size_t i;
qemu: monitor: Move processing of QMP schema to the new file The JSON array was processed to the hash table used by the query apis in the monitor code. Move it to a new helper in qemu_qapi.c. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-20 08:29:30 +00:00
if (!(schemareply = qemuMonitorQueryQMPSchema(mon)))
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
return -1;
qemu: monitor: Move processing of QMP schema to the new file The JSON array was processed to the hash table used by the query apis in the monitor code. Move it to a new helper in qemu_qapi.c. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-20 08:29:30 +00:00
if (!(schema = virQEMUQAPISchemaConvert(schemareply)))
return -1;
schemareply = NULL;
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
for (i = 0; i < ARRAY_CARDINALITY(virQEMUCapsQMPSchemaQueries); i++) {
entry = virQEMUCapsQMPSchemaQueries + i;
qemu: qapi: Fix naming of moved functions Change the prefix of the functions to 'virQEMUQapi' and rename the two public APIs so that the verb is put last. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-20 07:57:44 +00:00
if (virQEMUQAPISchemaPathExists(entry->value, schema))
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
virQEMUCapsSet(qemuCaps, entry->flag);
}
virHashFree(schema);
return 0;
}
Force QMP capability probing Remove the qmpOnly argument of virQEMUCapsNewForBinaryInternal and instead always assume it's true. This effectively sets the minimum QEMU version to 1.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-03-28 20:46:41 +00:00
#define QEMU_MIN_MAJOR 1
Require QEMU 1.5.0 According to the policy described on https://libvirt.org/platforms.html the QEMU versions in the oldest relevant releses are: SLES 12: 2.0.0 RHEL 7: 1.5.3 Ubuntu 14.04: 2.0.0 Set the minimum to 1.5.0 and drop support for RHEL 6. This will let us assume lots of capabilities. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-04-10 12:52:47 +00:00
#define QEMU_MIN_MINOR 5
Force QMP capability probing Remove the qmpOnly argument of virQEMUCapsNewForBinaryInternal and instead always assume it's true. This effectively sets the minimum QEMU version to 1.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-03-28 20:46:41 +00:00
#define QEMU_MIN_MICRO 0
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
int
virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
int ret = -1;
int major, minor, micro;
char *package = NULL;
/* @mon is supposed to be locked by callee */
if (qemuMonitorSetCapabilities(mon) < 0) {
VIR_DEBUG("Failed to set monitor capabilities %s",
qemu: Don't duplicate virGetLastErrorMessage These uses of virGetLastError message are just duplicating virGetLastErrorMessage.
2016-03-23 18:31:50 +00:00
virGetLastErrorMessage());
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
ret = 0;
goto cleanup;
}
if (qemuMonitorGetVersion(mon,
&major, &minor, &micro,
&package) < 0) {
VIR_DEBUG("Failed to query monitor version %s",
qemu: Don't duplicate virGetLastErrorMessage These uses of virGetLastError message are just duplicating virGetLastErrorMessage.
2016-03-23 18:31:50 +00:00
virGetLastErrorMessage());
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
ret = 0;
goto cleanup;
}
VIR_DEBUG("Got version %d.%d.%d (%s)",
major, minor, micro, NULLSTR(package));
Force QMP capability probing Remove the qmpOnly argument of virQEMUCapsNewForBinaryInternal and instead always assume it's true. This effectively sets the minimum QEMU version to 1.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-03-28 20:46:41 +00:00
if (major < QEMU_MIN_MAJOR ||
(major == QEMU_MIN_MAJOR && minor < QEMU_MIN_MINOR)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("QEMU version >= %d.%d.%d is required, but %d.%d.%d found"),
QEMU_MIN_MAJOR, QEMU_MIN_MINOR, QEMU_MIN_MICRO,
major, minor, micro);
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
goto cleanup;
}
qemuCaps->version = major * 1000000 + minor * 1000 + micro;
qemu: include libvirt & QEMU versions in QEMU log files It is often helpful to know which version of libvirt and QEMU was present when a guest was first launched. Ensure this info is written into the QEMU log file for each guest.
2015-02-02 10:28:30 +00:00
qemuCaps->package = package;
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
qemuCaps->usedQMP = true;
qemu: Split virQEMUCapsInitArchQMPBasic() Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
2017-03-27 14:42:17 +00:00
if (virQEMUCapsInitQMPArch(qemuCaps, mon) < 0)
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
goto cleanup;
qemu: Split virQEMUCapsInitArchQMPBasic() Instead of having a single function that probes the architecture from the monitor and then sets a bunch of basic capabilities based on it, have a separate function for each part: virQEMUCapsInitQMPArch() only sets the architecture, and virQEMUCapsInitQMPBasicArch() only sets the capabilities. This split will be useful later on, when we will want to set basic capabilities from the test suite without having to go through the pain of mocking the monitor.
2017-03-27 14:42:17 +00:00
virQEMUCapsInitQMPBasicArch(qemuCaps);
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
if (qemuCaps->version >= 1006000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
qemu: add QEMU_CAPS_MACHINE_VMPORT_OPT Set the capability based on qmp query, or qemu version. The qmp query includes vmport with 2.2, but no longer with 2.3. It lists only non-machine specific capabilities, so check the qemu version too until a machine-specific query is supported.
2015-04-02 16:43:47 +00:00
/* vmport option is supported v2.2.0 onwards */
if (qemuCaps->version >= 2002000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_VMPORT_OPT);
qemu: command: Support arm 32-on-64 KVM with -cpu aarch64=off qemu 2.3.0 added the -cpu host,aarch64=off option, which allows using qemu-system-aarch64 KVM to run armv7l VMs. Add a capabilities check for it, wire it up in qemu_command, and test the command line generation.
2015-05-21 22:18:20 +00:00
/* -cpu ...,aarch64=off supported in v2.3.0 and onwards. But it
isn't detectable via qmp at this point */
if (qemuCaps->arch == VIR_ARCH_AARCH64 &&
qemuCaps->version >= 2003000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_CPU_AARCH64_OFF);
qemu: Add capability for vhost-user multiqueue The support for this was added in QEMU with commit 830d70db692e374b55555f4407f96a1ceefdcc97. Unfortunately we have to do another ugly version-based capability check. The other option would be not to check for the capability at all and leave that to qemu as it's done with multiqueue tap devices. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-06-04 09:37:37 +00:00
/* vhost-user supports multi-queue from v2.4.0 onwards,
* but there is no way to query for that capability */
if (qemuCaps->version >= 2004000)
qemu caps: spell queue
2015-06-15 08:38:21 +00:00
virQEMUCapsSet(qemuCaps, QEMU_CAPS_VHOSTUSER_MULTIQUEUE);
qemu: Add capability for vhost-user multiqueue The support for this was added in QEMU with commit 830d70db692e374b55555f4407f96a1ceefdcc97. Unfortunately we have to do another ugly version-based capability check. The other option would be not to check for the capability at all and leave that to qemu as it's done with multiqueue tap devices. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-06-04 09:37:37 +00:00
Introduce SMM feature Since its release of 2.4.0 qemu is able to enable System Management Module in the firmware, or disable it. We should expose this capability in the XML. Unfortunately, there's no good way to determine whether the binary we are talking to supports it. I mean, if qemu's run with real machine type, the smm attribute can be seen in 'qom-list /machine' output. But it's not there when qemu's run with -M none. Therefore we're stuck with version based check. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-07-13 12:09:20 +00:00
/* smm option is supported from v2.4.0 */
if (qemuCaps->version >= 2004000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_SMM_OPT);
qemu: Add QEMU_CAPS_SDL_GL to qemu capabilities Support OpenGL acceleration capability when using SDL graphics. Signed-off-by: Maciej Wolny <maciej.wolny@codethink.co.uk> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-10 10:53:58 +00:00
/* sdl -gl option is supported from v2.4.0 (qemu commit id 0b71a5d5) */
if (qemuCaps->version >= 2004000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_SDL_GL);
qemu: Introduce QEMU_CAPS_MACH_VIRT_GIC_VERSION capability Unfortunately qemu currently doesn't offer introspection for machine types, so we have to rely on version number, similar to QEMU_CAPS_MACHINE_USB_OPT. Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
2015-09-30 11:04:09 +00:00
/* Since 2.4.50 ARM virt machine supports gic-version option */
if (qemuCaps->version >= 2004050)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACH_VIRT_GIC_VERSION);
qemu: format kernel_irqchip on the command line Add kernel_irqchip=split/on to the QEMU command line and a capability that looks for it in query-command-line-options output. For the 'split' option, use a version check since it cannot be reasonably probed. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-03-17 07:26:49 +00:00
/* no way to query if -machine kernel_irqchip supports split */
if (qemuCaps->version >= 2006000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_KERNEL_IRQCHIP_SPLIT);
qemu: Enable configuration of HPT resizing for pSeries guests Most of the time it's okay to leave this up to negotiation between the guest and the host, but in some situations it can be useful to manually decide the behavior, especially to enforce its availability. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1308743 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-11-06 15:39:40 +00:00
/* HPT resizing is supported since QEMU 2.10 on ppc64; unfortunately
* there's no sane way to probe for it */
if (qemuCaps->version >= 2010000 &&
ARCH_IS_PPC64(qemuCaps->arch)) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_PSERIES_RESIZE_HPT);
}
qemu: caps: Introduce a capability for egl-headless Since QEMU 2.10, it's possible to use a new type of display - egl-headless which uses drm nodes to provide OpenGL support. This patch adds a capability for that. However, since QEMU doesn't provide a QMP command to probe it, we have to base the capability on specific QEMU version. Acked-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Erik Skultety <eskultet@redhat.com>
2018-06-30 14:16:24 +00:00
/* '-display egl-headless' cmdline option is supported since QEMU 2.10, but
* there's no way to probe it */
if (qemuCaps->version >= 2010000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_EGL_HEADLESS);
qemu_capabilities: Introcude QEMU_CAPS_NUMA_DIST This capability says if qemu is capable of specifying distances between NUMA nodes on the command line. Unfortunately, there's no real way to check this and thus we have to go with version check. QEMU introduced this in 0f203430dd8 (and friend) which was released in 2.10.0. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-11-14 13:29:20 +00:00
/* no way to query for -numa dist */
if (qemuCaps->version >= 2010000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NUMA_DIST);
qemu: Add capability for pseries machine's max-cpu-compat= parameter Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-01-05 13:47:46 +00:00
/* no way to query max-cpu-compat */
if (qemuCaps->version >= 2010000 &&
ARCH_IS_PPC64(qemuCaps->arch)) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_PSERIES_MAX_CPU_COMPAT);
}
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
if (virQEMUCapsProbeQMPCommands(qemuCaps, mon) < 0)
goto cleanup;
qemu: Probe KVM state earlier Let's set QEMU_CAPS_KVM and QEMU_CAPS_ENABLE_KVM early so that the rest of the probing code can use these capabilities to handle KVM/TCG replies differently. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 17:14:52 +00:00
/* Some capabilities may differ depending on KVM state */
if (virQEMUCapsProbeQMPKVMState(qemuCaps, mon) < 0)
goto cleanup;
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
if (virQEMUCapsProbeQMPEvents(qemuCaps, mon) < 0)
goto cleanup;
qemu_capabilities: s/ObjectProps/DeviceProps/g So far all the properties we are trying to fetch are device properties, i.e. -device $dev on qemu command line. Change misleading variable names to express what's queried for better. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-12 11:31:03 +00:00
if (virQEMUCapsProbeQMPDevices(qemuCaps, mon) < 0)
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
goto cleanup;
if (virQEMUCapsProbeQMPMachineTypes(qemuCaps, mon) < 0)
goto cleanup;
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (virQEMUCapsProbeQMPCPUDefinitions(qemuCaps, mon, false) < 0)
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
goto cleanup;
if (virQEMUCapsProbeQMPTPM(qemuCaps, mon) < 0)
goto cleanup;
if (virQEMUCapsProbeQMPCommandLine(qemuCaps, mon) < 0)
goto cleanup;
qemu: Add RDMA migration capabilities
2014-09-11 12:11:54 +00:00
if (virQEMUCapsProbeQMPMigrationCapabilities(qemuCaps, mon) < 0)
goto cleanup;
qemu: capabilities: Add support for QMP schema introspection Allow detecting capabilities according to the qemu QMP schema. This is necessary as sometimes the availability of certain options depends on the presence of a field in the schema. This patch adds support for loading the QMP schema when detecting qemu capabilities and adds a very simple query language to allow traversing the schema and selecting a certain element from it. The infrastructure in this patch uses a query path to set a specific capability flag according to the availability of the given element in the schema.
2016-10-19 12:40:53 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_QMP_SCHEMA) &&
virQEMUCapsProbeQMPSchemaCapabilities(qemuCaps, mon) < 0)
goto cleanup;
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
if (virQEMUCapsProbeQMPHostCPU(qemuCaps, mon, false) < 0)
qemu-caps: Get host model directly from Qemu when available When qmp query-cpu-model-expansion is available probe Qemu for its view of the host model. In kvm environments this can provide a more complete view of the host model because features supported by Qemu and Kvm can be considered. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
2017-01-06 07:52:22 +00:00
goto cleanup;
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
qemu: fix command line building for iommu devices The intel-iommu device has existed since QEMU 2.2.0, but it was only possible to create it with -device since QEMU 2.7.0, thanks to: commit 621d983a1f9051f4cfc3f402569b46b77d8449fc Author: Marcel Apfelbaum <marcel@redhat.com> Date: Mon Jun 27 18:38:34 2016 +0300 hw/iommu: enable iommu with -device Use the standard '-device intel-iommu' to create the IOMMU device. The legacy '-machine,iommu=on' can still be used. The libvirt capability check & command line formatting code is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive. This fixes it to use iommu=on instead. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-10-03 12:31:12 +00:00
/* 'intel-iommu' shows up as a device since 2.2.0, but can
* not be used with -device until 2.7.0. Before that it
* requires -machine iommu=on. So we must clear the device
* capability we detected on older QEMUs
*/
if (qemuCaps->version < 2007000 &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_INTEL_IOMMU)) {
virQEMUCapsClear(qemuCaps, QEMU_CAPS_DEVICE_INTEL_IOMMU);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_IOMMU);
}
qemu: Probe GIC capabilities QEMU introduced the query-gic-capabilities QMP command with commit 4468d4e0f383: use the command, if available, to probe available GIC capabilities. The information obtained is stored in a virQEMUCaps instance, and will be later used to fill in a virDomainCaps instance.
2016-03-08 17:24:18 +00:00
/* GIC capabilities, eg. available GIC versions */
if ((qemuCaps->arch == VIR_ARCH_AARCH64 ||
qemuCaps->arch == VIR_ARCH_ARMV7L) &&
virQEMUCapsProbeQMPGICCapabilities(qemuCaps, mon) < 0)
goto cleanup;
qemu: Introduce QEMU_CAPS_DEVICE_NVDIMM Introduce a qemu capability for -device nvdimm. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-07-29 06:17:42 +00:00
/* Prealloc on NVDIMMs is broken on older QEMUs leading to
* user data corruption. If we are dealing with such version
* of QEMU pretend we don't know how to NVDIMM. */
if (qemuCaps->version < 2009000 &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_NVDIMM))
virQEMUCapsClear(qemuCaps, QEMU_CAPS_DEVICE_NVDIMM);
qemu: Add support for guest CPU cache This patch maps /domain/cpu/cache element into -cpu parameters: - <cache mode='passthrough'/> is translated to host-cache-info=on - <cache level='3' mode='emulate'/> is transformed into l3-cache=on - <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off Any other <cache> element is forbidden. The tricky part is detecting whether QEMU supports the CPU properties. The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480, earlier QEMU releases enabled host-cache-info by default and had no way to disable it. If the property is present, it defaults to 'off' for any QEMU until at least 2.9.0. The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa. Earlier versions worked as if l3-cache=off was passed. For any QEMU until at least 2.9.0 l3-cache is 'off' by default. QEMU 2.9.0 was the first release which supports probing both properties by running device-list-properties with typename=host-x86_64-cpu. Older QEMU releases did not support device-list-properties command for CPU devices. Thus we can't really rely on probing them and we can just use query-cpu-model-expansion QMP command as a witness. Because the cache property probing is only reliable for QEMU >= 2.9.0 when both are already supported for quite a few releases, we let QEMU report an error if a specific cache mode is explicitly requested. The other mode (or both if a user requested CPU cache to be disabled) is explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case the QEMU defaults change. Any older QEMU already turns them off so not doing so explicitly does not make any harm. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-25 17:07:19 +00:00
if (ARCH_IS_X86(qemuCaps->arch) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION))
virQEMUCapsSet(qemuCaps, QEMU_CAPS_CPU_CACHE);
qemu: introduce capability for virtual-css-bridge Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments which identify support for ccw devices. The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7. The QEMU_CAPS_CCW capability is based on the existence of the QEMU type. Let us also add the capability QEMU_CAPS_CCW to the tests which require support for ccw devices. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:11 +00:00
if (ARCH_IS_S390(qemuCaps->arch)) {
/* Legacy assurance for QEMU_CAPS_CCW */
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CCW) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_CCW))
virQEMUCapsSet(qemuCaps, QEMU_CAPS_CCW);
qemu: introduce vfio-ccw capability Let us introduce the capability vfio-ccw for supporting the basic channel I/O passthrough, which have been introduced in QEMU 2.10. The current focus is to support dasd-eckd (cu_type/dev_type = 0x3990/0x3390) as the target device. Let us also introduce the capability QEMU_CAPS_CCW_CSSID_UNRESTRICTED for virtual-css-bridge. This capability is based on the cssid-unrestricted property which exists if QEMU no longer enforces cssid restrictions based on ccw device types. Vfio-ccw capability is dependent on the hidden virtual-css-bridge, so that we are able to probe for the cssid-unrestriced property to make sure the devices are visible to non-mcss-e enabled guests. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:12 +00:00
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CCW_CSSID_UNRESTRICTED))
virQEMUCapsClear(qemuCaps, QEMU_CAPS_DEVICE_VFIO_CCW);
qemu: introduce capability for virtual-css-bridge Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments which identify support for ccw devices. The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7. The QEMU_CAPS_CCW capability is based on the existence of the QEMU type. Let us also add the capability QEMU_CAPS_CCW to the tests which require support for ccw devices. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-05-07 14:41:11 +00:00
}
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
/* Probe for SEV capabilities */
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_GUEST)) {
qemu: Fix probing of AMD SEV support So the procedure to detect SEV support works like this: 1) we detect that sev-guest is among the QOM types and set the cap flag 2) we probe the monitor for SEV support - this is tricky, because QEMU with compiled SEV support will always report -object sev-guest and query-sev-capabilities command, that however doesn't mean SEV is supported 3) depending on what the monitor returned, we either keep or clear the capability flag for SEV Commit a349c6c21c6 added an explicit check for "GenericError" in the monitor reply to prevent libvirtd to spam logs about missing 'query-sev-capabilities' command. At the same time though, it returned success in this case which means that we didn't clear the capability flag afterwards and happily formatted SEV into qemuCaps. Therefore, adjust all the relevant callers to handle -1 on errors, 0 on SEV being unsupported and 1 on SEV being supported. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-14 13:54:46 +00:00
int rc = virQEMUCapsProbeQMPSEVCapabilities(qemuCaps, mon);
if (rc < 0)
goto cleanup;
if (rc == 0)
qemu: Provide support to query the SEV capability QEMU version >= 2.12 provides support for launching an encrypted VMs on AMD x86 platform using Secure Encrypted Virtualization (SEV) feature. This patch adds support to query the SEV capability from the qemu. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:51 +00:00
virQEMUCapsClear(qemuCaps, QEMU_CAPS_SEV_GUEST);
}
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
ret = 0;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
cleanup:
qemu_capabilities: Introduce virQEMUCapsInitQMPMonitor This basically covers the talking-to-monitor part of virQEMUCapsInitQMP. The patch itself has no real value, but it creates an entity to be tested in the next patches. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:14:25 +00:00
return ret;
}
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
qemu: Enable KVM when probing capabilities CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities: QEMU_CAPS_KVM is set QEMU_CAPS_ENABLE_KVM is not set - TCG was used and QEMU supports KVM, but it failed (e.g., missing kernel module or wrong /dev/kvm permissions) QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is set - KVM was not used and QEMU does not support it QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is not set Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 15:16:21 +00:00
int
virQEMUCapsInitQMPMonitorTCG(virQEMUCapsPtr qemuCaps ATTRIBUTE_UNUSED,
qemuMonitorPtr mon)
{
int ret = -1;
if (qemuMonitorSetCapabilities(mon) < 0) {
VIR_DEBUG("Failed to set monitor capabilities %s",
virGetLastErrorMessage());
ret = 0;
goto cleanup;
}
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
if (virQEMUCapsProbeQMPCPUDefinitions(qemuCaps, mon, true) < 0)
goto cleanup;
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
if (virQEMUCapsProbeQMPHostCPU(qemuCaps, mon, true) < 0)
goto cleanup;
qemu: Enable KVM when probing capabilities CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities: QEMU_CAPS_KVM is set QEMU_CAPS_ENABLE_KVM is not set - TCG was used and QEMU supports KVM, but it failed (e.g., missing kernel module or wrong /dev/kvm permissions) QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is set - KVM was not used and QEMU does not support it QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is not set Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 15:16:21 +00:00
ret = 0;
cleanup:
return ret;
}
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
typedef struct _virQEMUCapsInitQMPCommand virQEMUCapsInitQMPCommand;
typedef virQEMUCapsInitQMPCommand *virQEMUCapsInitQMPCommandPtr;
struct _virQEMUCapsInitQMPCommand {
char *binary;
uid_t runUid;
gid_t runGid;
char **qmperr;
char *monarg;
char *monpath;
char *pidfile;
virCommandPtr cmd;
qemuMonitorPtr mon;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
virDomainChrSourceDef config;
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
pid_t pid;
virDomainObjPtr vm;
};
static void
virQEMUCapsInitQMPCommandAbort(virQEMUCapsInitQMPCommandPtr cmd)
{
if (cmd->mon)
virObjectUnlock(cmd->mon);
qemuMonitorClose(cmd->mon);
cmd->mon = NULL;
virCommandAbort(cmd->cmd);
virCommandFree(cmd->cmd);
cmd->cmd = NULL;
if (cmd->monpath)
ignore_value(unlink(cmd->monpath));
virDomainObjEndAPI(&cmd->vm);
if (cmd->pid != 0) {
char ebuf[1024];
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
VIR_DEBUG("Killing QMP caps process %lld", (long long)cmd->pid);
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
if (virProcessKill(cmd->pid, SIGKILL) < 0 && errno != ESRCH)
VIR_ERROR(_("Failed to kill process %lld: %s"),
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
(long long)cmd->pid,
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
virStrerror(errno, ebuf, sizeof(ebuf)));
VIR_FREE(*cmd->qmperr);
}
if (cmd->pidfile)
unlink(cmd->pidfile);
cmd->pid = 0;
}
static void
virQEMUCapsInitQMPCommandFree(virQEMUCapsInitQMPCommandPtr cmd)
{
if (!cmd)
return;
virQEMUCapsInitQMPCommandAbort(cmd);
VIR_FREE(cmd->binary);
VIR_FREE(cmd->monpath);
VIR_FREE(cmd->monarg);
VIR_FREE(cmd->pidfile);
VIR_FREE(cmd);
}
static virQEMUCapsInitQMPCommandPtr
virQEMUCapsInitQMPCommandNew(char *binary,
const char *libDir,
uid_t runUid,
gid_t runGid,
char **qmperr)
{
virQEMUCapsInitQMPCommandPtr cmd = NULL;
if (VIR_ALLOC(cmd) < 0)
goto error;
if (VIR_STRDUP(cmd->binary, binary) < 0)
goto error;
cmd->runUid = runUid;
cmd->runGid = runGid;
cmd->qmperr = qmperr;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu: Kill processes used for QMP caps probing Since libvirt switched to QMP capabilities probing recently, it starts QEMU process used for this probing with -daemonize, which means virCommandAbort can no longer reach these processes. As a result of that, restarting libvirtd will leave several new QEMU processes behind. Let's use QEMU's -pidfile and use it to kill the process when QMP caps probing is done.
2012-10-02 08:59:56 +00:00
/* the ".sock" sufix is important to avoid a possible clash with a qemu
* domain called "capabilities"
*/
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
if (virAsprintf(&cmd->monpath, "%s/%s", libDir,
"capabilities.monitor.sock") < 0)
goto error;
if (virAsprintf(&cmd->monarg, "unix:%s,server,nowait", cmd->monpath) < 0)
goto error;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu: Kill processes used for QMP caps probing Since libvirt switched to QMP capabilities probing recently, it starts QEMU process used for this probing with -daemonize, which means virCommandAbort can no longer reach these processes. As a result of that, restarting libvirtd will leave several new QEMU processes behind. Let's use QEMU's -pidfile and use it to kill the process when QMP caps probing is done.
2012-10-02 08:59:56 +00:00
/* ".pidfile" suffix is used rather than ".pid" to avoid a possible clash
* with a qemu domain called "capabilities"
Fix performance & reliabilty of QMP probing This previous commit commit 1a50ba2cb07d8bb2aa724062889deb9efd7ad9e9 Author: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Date: Mon Nov 26 15:17:13 2012 +0100 qemu: Fix QMP Capabability Probing Failure which attempted to make sure the QEMU process used for probing ran as the right user id, caused serious performance regression and unreliability in probing. The -daemonize switch in QEMU guarantees that the monitor socket is present before the parent process exits. This means libvirtd is guaranteed to be able to connect immediately. By switching from -daemonize to the virCommandDaemonize API libvirtd was no longer synchronized with QEMU's startup process. The result was that the QEMU monitor failed to open and went into its 200ms sleep loop. This happened for all 25 binaries resulting in 5 seconds worth of sleeping at libvirtd startup. In addition sometimes when libvirt connected, QEMU would be partially initialized and crash causing total failure to probe that binary. This commit reverts the previous change, ensuring we do use the -daemonize flag to QEMU. Startup delay is cut from 7 seconds to 2 seconds on my machine, which is on a par with what it was prior to the capabilities rewrite. To deal with the fact that QEMU needs to be able to create the pidfile, we switch pidfile location fron runDir to libDir, which QEMU is guaranteed to be able to write to. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-01-24 18:21:23 +00:00
* Normally we'd use runDir for pid files, but because we're using
* -daemonize we need QEMU to be allowed to create them, rather
* than libvirtd. So we're using libDir which QEMU can write to
qemu: Kill processes used for QMP caps probing Since libvirt switched to QMP capabilities probing recently, it starts QEMU process used for this probing with -daemonize, which means virCommandAbort can no longer reach these processes. As a result of that, restarting libvirtd will leave several new QEMU processes behind. Let's use QEMU's -pidfile and use it to kill the process when QMP caps probing is done.
2012-10-02 08:59:56 +00:00
*/
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
if (virAsprintf(&cmd->pidfile, "%s/%s", libDir, "capabilities.pidfile") < 0)
goto error;
qemu: Kill processes used for QMP caps probing Since libvirt switched to QMP capabilities probing recently, it starts QEMU process used for this probing with -daemonize, which means virCommandAbort can no longer reach these processes. As a result of that, restarting libvirtd will leave several new QEMU processes behind. Let's use QEMU's -pidfile and use it to kill the process when QMP caps probing is done.
2012-10-02 08:59:56 +00:00
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
virPidFileForceCleanupPath(cmd->pidfile);
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
cmd->config.type = VIR_DOMAIN_CHR_TYPE_UNIX;
cmd->config.data.nix.path = cmd->monpath;
cmd->config.data.nix.listen = false;
qemu: make sure capability probing process can start When daemon is killed right in the middle of probing a qemu binary for its capabilities, the qemu process is left running. Next time the daemon is starting, it cannot start the probing qemu process because the one that's already running does have the pidfile flock()'d. Reported-by: Wang Yufei <james.wangyufei@huawei.com> Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-10-09 06:18:33 +00:00
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
return cmd;
error:
virQEMUCapsInitQMPCommandFree(cmd);
return NULL;
}
/* Returns -1 on fatal error,
* 0 on success,
* 1 when probing QEMU failed
*/
static int
qemu: Enable KVM when probing capabilities CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities: QEMU_CAPS_KVM is set QEMU_CAPS_ENABLE_KVM is not set - TCG was used and QEMU supports KVM, but it failed (e.g., missing kernel module or wrong /dev/kvm permissions) QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is set - KVM was not used and QEMU does not support it QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is not set Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 15:16:21 +00:00
virQEMUCapsInitQMPCommandRun(virQEMUCapsInitQMPCommandPtr cmd,
bool forceTCG)
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
{
virDomainXMLOptionPtr xmlopt = NULL;
qemu: Enable KVM when probing capabilities CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities: QEMU_CAPS_KVM is set QEMU_CAPS_ENABLE_KVM is not set - TCG was used and QEMU supports KVM, but it failed (e.g., missing kernel module or wrong /dev/kvm permissions) QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is set - KVM was not used and QEMU does not support it QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is not set Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 15:16:21 +00:00
const char *machine;
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
int status = 0;
int ret = -1;
qemu: Enable KVM when probing capabilities CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities: QEMU_CAPS_KVM is set QEMU_CAPS_ENABLE_KVM is not set - TCG was used and QEMU supports KVM, but it failed (e.g., missing kernel module or wrong /dev/kvm permissions) QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is set - KVM was not used and QEMU does not support it QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is not set Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 15:16:21 +00:00
if (forceTCG)
machine = "none,accel=tcg";
else
machine = "none,accel=kvm:tcg";
VIR_DEBUG("Try to probe capabilities of '%s' via QMP, machine %s",
cmd->binary, machine);
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
Fix performance & reliabilty of QMP probing This previous commit commit 1a50ba2cb07d8bb2aa724062889deb9efd7ad9e9 Author: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Date: Mon Nov 26 15:17:13 2012 +0100 qemu: Fix QMP Capabability Probing Failure which attempted to make sure the QEMU process used for probing ran as the right user id, caused serious performance regression and unreliability in probing. The -daemonize switch in QEMU guarantees that the monitor socket is present before the parent process exits. This means libvirtd is guaranteed to be able to connect immediately. By switching from -daemonize to the virCommandDaemonize API libvirtd was no longer synchronized with QEMU's startup process. The result was that the QEMU monitor failed to open and went into its 200ms sleep loop. This happened for all 25 binaries resulting in 5 seconds worth of sleeping at libvirtd startup. In addition sometimes when libvirt connected, QEMU would be partially initialized and crash causing total failure to probe that binary. This commit reverts the previous change, ensuring we do use the -daemonize flag to QEMU. Startup delay is cut from 7 seconds to 2 seconds on my machine, which is on a par with what it was prior to the capabilities rewrite. To deal with the fact that QEMU needs to be able to create the pidfile, we switch pidfile location fron runDir to libDir, which QEMU is guaranteed to be able to write to. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-01-24 18:21:23 +00:00
/*
* We explicitly need to use -daemonize here, rather than
* virCommandDaemonize, because we need to synchronize
* with QEMU creating its monitor socket API. Using
* daemonize guarantees control won't return to libvirt
* until the socket is present.
*/
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
cmd->cmd = virCommandNewArgList(cmd->binary,
"-S",
"-no-user-config",
"-nodefaults",
"-nographic",
qemu: Enable KVM when probing capabilities CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities: QEMU_CAPS_KVM is set QEMU_CAPS_ENABLE_KVM is not set - TCG was used and QEMU supports KVM, but it failed (e.g., missing kernel module or wrong /dev/kvm permissions) QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is set - KVM was not used and QEMU does not support it QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is not set Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 15:16:21 +00:00
"-machine", machine,
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
"-qmp", cmd->monarg,
"-pidfile", cmd->pidfile,
"-daemonize",
NULL);
virCommandAddEnvPassCommon(cmd->cmd);
virCommandClearCaps(cmd->cmd);
virCommandSetGID(cmd->cmd, cmd->runGid);
virCommandSetUID(cmd->cmd, cmd->runUid);
virCommandSetErrorBuffer(cmd->cmd, cmd->qmperr);
Report original error when QMP probing fails with new QEMU If probing capabilities via QMP fails, we now have a check that prevents us falling back to -help parsing. Unfortunately the error message "Failed to probe capabilities for /usr/bin/qemu-kvm: unsupported configuration: QEMU 2.1.2 is too new for help parsing" is proving rather unhelpful to the user. We need to be telling them why QMP failed (the root cause), rather than they can't use -help (the side effect). To do this we should capture stderr during QMP probing, and if -help parsing then sees a new QEMU version, we know that QMP should have worked, and so we can show the messages from stderr. The message thus becomes "Failed to probe capabilities for /usr/bin/qemu-kvm: internal error: QEMU / QMP failed: Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory"
2014-12-04 15:26:41 +00:00
util: make it easier to grab only regular command exit Auditing all callers of virCommandRun and virCommandWait that passed a non-NULL pointer for exit status turned up some interesting observations. Many callers were merely passing a pointer to avoid the overall command dying, but without caring what the exit status was - but these callers would be better off treating a child death by signal as an abnormal exit. Other callers were actually acting on the status, but not all of them remembered to filter by WIFEXITED and convert with WEXITSTATUS; depending on the platform, this can result in a status being reported as 256 times too big. And among those that correctly parse the output, it gets rather verbose. Finally, there were the callers that explicitly checked that the status was 0, and gave their own message, but with fewer details than what virCommand gives for free. So the best idea is to move the complexity out of callers and into virCommand - by default, we return the actual exit status already cleaned through WEXITSTATUS and treat signals as a failed command; but the few callers that care can ask for raw status and act on it themselves. * src/util/vircommand.h (virCommandRawStatus): New prototype. * src/libvirt_private.syms (util/command.h): Export it. * docs/internals/command.html.in: Document it. * src/util/vircommand.c (virCommandRawStatus): New function. (virCommandWait): Adjust semantics. * tests/commandtest.c (test1): Test it. * daemon/remote.c (remoteDispatchAuthPolkit): Adjust callers. * src/access/viraccessdriverpolkit.c (virAccessDriverPolkitCheck): Likewise. * src/fdstream.c (virFDStreamCloseInt): Likewise. * src/lxc/lxc_process.c (virLXCProcessStart): Likewise. * src/qemu/qemu_command.c (qemuCreateInBridgePortWithHelper): Likewise. * src/xen/xen_driver.c (xenUnifiedXendProbe): Simplify. * tests/reconnect.c (mymain): Likewise. * tests/statstest.c (mymain): Likewise. * src/bhyve/bhyve_process.c (virBhyveProcessStart) (virBhyveProcessStop): Don't overwrite virCommand error. * src/libvirt.c (virConnectAuthGainPolkit): Likewise. * src/openvz/openvz_driver.c (openvzDomainGetBarrierLimit) (openvzDomainSetBarrierLimit): Likewise. * src/util/virebtables.c (virEbTablesOnceInit): Likewise. * src/util/viriptables.c (virIpTablesOnceInit): Likewise. * src/util/virnetdevveth.c (virNetDevVethCreate): Fix debug message. * src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Add comment. * src/storage/storage_backend_iscsi.c (virStorageBackendISCSINodeUpdate): Likewise. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-02-20 00:32:19 +00:00
/* Log, but otherwise ignore, non-zero status. */
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
if (virCommandRun(cmd->cmd, &status) < 0)
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
goto cleanup;
if (status != 0) {
Report original error when QMP probing fails with new QEMU If probing capabilities via QMP fails, we now have a check that prevents us falling back to -help parsing. Unfortunately the error message "Failed to probe capabilities for /usr/bin/qemu-kvm: unsupported configuration: QEMU 2.1.2 is too new for help parsing" is proving rather unhelpful to the user. We need to be telling them why QMP failed (the root cause), rather than they can't use -help (the side effect). To do this we should capture stderr during QMP probing, and if -help parsing then sees a new QEMU version, we know that QMP should have worked, and so we can show the messages from stderr. The message thus becomes "Failed to probe capabilities for /usr/bin/qemu-kvm: internal error: QEMU / QMP failed: Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory"
2014-12-04 15:26:41 +00:00
VIR_DEBUG("QEMU %s exited with status %d: %s",
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
cmd->binary, status, *cmd->qmperr);
goto ignore;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
}
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
if (virPidFileReadPath(cmd->pidfile, &cmd->pid) < 0) {
VIR_DEBUG("Failed to read pidfile %s", cmd->pidfile);
goto ignore;
Speed up fallback to legacy non-QMP probing Since we daemonized QEMU for capabilities probing there is a long time if QEMU fails to launch. This is because we're not passing in any virDomainObjPtr instance and thus the monitor code can not check to see if the PID is still alive. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-01-07 16:19:36 +00:00
}
conf: Add save cookie callbacks to xmlopt virDomainXMLOption gains driver specific callbacks for parsing and formatting save cookies. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-06-01 22:44:46 +00:00
if (!(xmlopt = virDomainXMLOptionNew(NULL, NULL, NULL, NULL, NULL)) ||
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
!(cmd->vm = virDomainObjNew(xmlopt)))
qemu_migration: Avoid crashing if domain dies too quickly I've noticed a SIGSEGV-ing libvirtd on the destination when the qemu died too quickly = in Prepare phase. What is happening here is: 1) [Thread 3493] We are in qemuMigrationPrepareAny() and calling qemuProcessStart() which subsequently calls qemuProcessWaitForMonitor() and qemuConnectMonitor(). So far so good. The qemuMonitorOpen() succeeds, however switching monitor to QMP mode fails as qemu died meanwhile. That is qemuMonitorSetCapabilities() returns -1. 2013-10-08 15:54:10.629+0000: 3493: debug : qemuMonitorSetCapabilities:1356 : mon=0x14a53da0 2013-10-08 15:54:10.630+0000: 3493: debug : qemuMonitorJSONCommandWithFd:262 : Send command '{"execute":"qmp_capabilities","id":"libvirt-1"}' for write with FD -1 2013-10-08 15:54:10.630+0000: 3493: debug : virEventPollUpdateHandle:147 : EVENT_POLL_UPDATE_HANDLE: watch=17 events=13 ... 2013-10-08 15:54:10.631+0000: 3493: debug : qemuMonitorSend:956 : QEMU_MONITOR_SEND_MSG: mon=0x14a53da0 msg={"execute":"qmp_capabilities","id":"libvirt-1"} fd=-1 2013-10-08 15:54:10.631+0000: 3262: debug : virEventPollRunOnce:641 : Poll got 1 event(s) 2) [Thread 3262] The event loop is trying to do the talking to monitor. However, qemu is dead already, remember? 2013-10-08 15:54:13.436+0000: 3262: error : qemuMonitorIORead:551 : Unable to read from monitor: Connection reset by peer 2013-10-08 15:54:13.516+0000: 3262: debug : virFileClose:90 : Closed fd 25 ... 2013-10-08 15:54:13.533+0000: 3493: debug : qemuMonitorSend:968 : Send command resulted in error internal error: early end of file from monitor: possible problem: 3) [Thread 3493] qemuProcessStart() failed. No big deal. Go to the 'endjob' label and subsequently to the 'cleanup'. Since the domain is not persistent and ret is -1, the qemuDomainRemoveInactive() is called. This has an (unpleasant) effect of virObjectUnref()-in the @vm object. Unpleasant because the event loop which is about to trigger EOF callback still holds a pointer to the @vm (not the reference). See the valgrind output below. 4) [Thread 3262] So the event loop starts triggering EOF: 2013-10-08 15:54:13.542+0000: 3262: debug : qemuMonitorIO:729 : Triggering EOF callback 2013-10-08 15:54:13.543+0000: 3262: debug : qemuProcessHandleMonitorEOF:294 : Received EOF on 0x14549110 'migt10' And the monitor is cleaned up. This results in calling qemuProcessHandleMonitorEOF with the @vm pointer passed. The pointer is kept in qemuMonitor struct. ==3262== Thread 1: ==3262== Invalid read of size 4 ==3262== at 0x77ECCAA: pthread_mutex_lock (in /lib64/libpthread-2.15.so) ==3262== by 0x52FAA06: virMutexLock (virthreadpthread.c:85) ==3262== by 0x52E3891: virObjectLock (virobject.c:320) ==3262== by 0x11626743: qemuProcessHandleMonitorEOF (qemu_process.c:296) ==3262== by 0x11642593: qemuMonitorIO (qemu_monitor.c:730) ==3262== by 0x52BD526: virEventPollDispatchHandles (vireventpoll.c:501) ==3262== by 0x52BDD49: virEventPollRunOnce (vireventpoll.c:648) ==3262== by 0x52BBC68: virEventRunDefaultImpl (virevent.c:274) ==3262== by 0x542D3D9: virNetServerRun (virnetserver.c:1112) ==3262== by 0x11F368: main (libvirtd.c:1513) ==3262== Address 0x14549128 is 24 bytes inside a block of size 136 free'd ==3262== at 0x4C2AF5C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3262== by 0x529B1FF: virFree (viralloc.c:580) ==3262== by 0x52E3703: virObjectUnref (virobject.c:270) ==3262== by 0x531557E: virDomainObjListRemove (domain_conf.c:2355) ==3262== by 0x1160E899: qemuDomainRemoveInactive (qemu_domain.c:2061) ==3262== by 0x1163A0C6: qemuMigrationPrepareAny (qemu_migration.c:2450) ==3262== by 0x1163A923: qemuMigrationPrepareDirect (qemu_migration.c:2626) ==3262== by 0x11682D71: qemuDomainMigratePrepare3Params (qemu_driver.c:10309) ==3262== by 0x53B0976: virDomainMigratePrepare3Params (libvirt.c:7266) ==3262== by 0x1502D3: remoteDispatchDomainMigratePrepare3Params (remote.c:4797) ==3262== by 0x12DECA: remoteDispatchDomainMigratePrepare3ParamsHelper (remote_dispatch.h:5741) ==3262== by 0x54322EB: virNetServerProgramDispatchCall (virnetserverprogram.c:435) The mon->vm is set in qemuMonitorOpenInternal() which is the correct place to increase @vm ref counter. The correct place to decrease the ref counter is then qemuMonitorDispose(). Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-08 14:50:33 +00:00
goto cleanup;
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
cmd->vm->pid = cmd->pid;
Speed up fallback to legacy non-QMP probing Since we daemonized QEMU for capabilities probing there is a long time if QEMU fails to launch. This is because we're not passing in any virDomainObjPtr instance and thus the monitor code can not check to see if the PID is still alive. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-01-07 16:19:36 +00:00
qemu: don't retry connect() if doing FD passing Since libvirt called bind() and listen() on the UNIX socket, it is guaranteed that connect() will immediately succeed, if QEMU is running normally. It will only fail if QEMU has closed the monitor socket by mistake or if QEMU has exited, letting the kernel close it. With this in mind we can remove the retry loop and timeout when connecting to the QEMU monitor if we are doing FD passing. Libvirt can go straight to sending the QMP greeting and will simply block waiting for a reply until QEMU is ready. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-14 17:27:49 +00:00
if (!(cmd->mon = qemuMonitorOpen(cmd->vm, &cmd->config, true, true,
qemu: Adaptive timeout for connecting to monitor There were couple of reports on the list (e.g. [1]) that guests with huge amounts of RAM are unable to start because libvirt kills qemu in the initialization phase. The problem is that if guest is configured to use hugepages kernel has to zero them all out before handing over to qemu process. For instance, 402GiB worth of 1GiB pages took around 105 seconds (~3.8GiB/s). Since we do not want to make the timeout for connecting to monitor configurable, we have to teach libvirt to count with this fact. This commit implements "1s per each 1GiB of RAM" approach as suggested here [2]. 1: https://www.redhat.com/archives/libvir-list/2017-March/msg00373.html 2: https://www.redhat.com/archives/libvir-list/2017-March/msg00405.html Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-03-11 06:23:42 +00:00
0, &callbacks, NULL)))
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
goto ignore;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
virObjectLock(cmd->mon);
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
ret = 0;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
cleanup:
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
if (!cmd->mon)
virQEMUCapsInitQMPCommandAbort(cmd);
qemu_migration: Avoid crashing if domain dies too quickly I've noticed a SIGSEGV-ing libvirtd on the destination when the qemu died too quickly = in Prepare phase. What is happening here is: 1) [Thread 3493] We are in qemuMigrationPrepareAny() and calling qemuProcessStart() which subsequently calls qemuProcessWaitForMonitor() and qemuConnectMonitor(). So far so good. The qemuMonitorOpen() succeeds, however switching monitor to QMP mode fails as qemu died meanwhile. That is qemuMonitorSetCapabilities() returns -1. 2013-10-08 15:54:10.629+0000: 3493: debug : qemuMonitorSetCapabilities:1356 : mon=0x14a53da0 2013-10-08 15:54:10.630+0000: 3493: debug : qemuMonitorJSONCommandWithFd:262 : Send command '{"execute":"qmp_capabilities","id":"libvirt-1"}' for write with FD -1 2013-10-08 15:54:10.630+0000: 3493: debug : virEventPollUpdateHandle:147 : EVENT_POLL_UPDATE_HANDLE: watch=17 events=13 ... 2013-10-08 15:54:10.631+0000: 3493: debug : qemuMonitorSend:956 : QEMU_MONITOR_SEND_MSG: mon=0x14a53da0 msg={"execute":"qmp_capabilities","id":"libvirt-1"} fd=-1 2013-10-08 15:54:10.631+0000: 3262: debug : virEventPollRunOnce:641 : Poll got 1 event(s) 2) [Thread 3262] The event loop is trying to do the talking to monitor. However, qemu is dead already, remember? 2013-10-08 15:54:13.436+0000: 3262: error : qemuMonitorIORead:551 : Unable to read from monitor: Connection reset by peer 2013-10-08 15:54:13.516+0000: 3262: debug : virFileClose:90 : Closed fd 25 ... 2013-10-08 15:54:13.533+0000: 3493: debug : qemuMonitorSend:968 : Send command resulted in error internal error: early end of file from monitor: possible problem: 3) [Thread 3493] qemuProcessStart() failed. No big deal. Go to the 'endjob' label and subsequently to the 'cleanup'. Since the domain is not persistent and ret is -1, the qemuDomainRemoveInactive() is called. This has an (unpleasant) effect of virObjectUnref()-in the @vm object. Unpleasant because the event loop which is about to trigger EOF callback still holds a pointer to the @vm (not the reference). See the valgrind output below. 4) [Thread 3262] So the event loop starts triggering EOF: 2013-10-08 15:54:13.542+0000: 3262: debug : qemuMonitorIO:729 : Triggering EOF callback 2013-10-08 15:54:13.543+0000: 3262: debug : qemuProcessHandleMonitorEOF:294 : Received EOF on 0x14549110 'migt10' And the monitor is cleaned up. This results in calling qemuProcessHandleMonitorEOF with the @vm pointer passed. The pointer is kept in qemuMonitor struct. ==3262== Thread 1: ==3262== Invalid read of size 4 ==3262== at 0x77ECCAA: pthread_mutex_lock (in /lib64/libpthread-2.15.so) ==3262== by 0x52FAA06: virMutexLock (virthreadpthread.c:85) ==3262== by 0x52E3891: virObjectLock (virobject.c:320) ==3262== by 0x11626743: qemuProcessHandleMonitorEOF (qemu_process.c:296) ==3262== by 0x11642593: qemuMonitorIO (qemu_monitor.c:730) ==3262== by 0x52BD526: virEventPollDispatchHandles (vireventpoll.c:501) ==3262== by 0x52BDD49: virEventPollRunOnce (vireventpoll.c:648) ==3262== by 0x52BBC68: virEventRunDefaultImpl (virevent.c:274) ==3262== by 0x542D3D9: virNetServerRun (virnetserver.c:1112) ==3262== by 0x11F368: main (libvirtd.c:1513) ==3262== Address 0x14549128 is 24 bytes inside a block of size 136 free'd ==3262== at 0x4C2AF5C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3262== by 0x529B1FF: virFree (viralloc.c:580) ==3262== by 0x52E3703: virObjectUnref (virobject.c:270) ==3262== by 0x531557E: virDomainObjListRemove (domain_conf.c:2355) ==3262== by 0x1160E899: qemuDomainRemoveInactive (qemu_domain.c:2061) ==3262== by 0x1163A0C6: qemuMigrationPrepareAny (qemu_migration.c:2450) ==3262== by 0x1163A923: qemuMigrationPrepareDirect (qemu_migration.c:2626) ==3262== by 0x11682D71: qemuDomainMigratePrepare3Params (qemu_driver.c:10309) ==3262== by 0x53B0976: virDomainMigratePrepare3Params (libvirt.c:7266) ==3262== by 0x1502D3: remoteDispatchDomainMigratePrepare3Params (remote.c:4797) ==3262== by 0x12DECA: remoteDispatchDomainMigratePrepare3ParamsHelper (remote_dispatch.h:5741) ==3262== by 0x54322EB: virNetServerProgramDispatchCall (virnetserverprogram.c:435) The mon->vm is set in qemuMonitorOpenInternal() which is the correct place to increase @vm ref counter. The correct place to decrease the ref counter is then qemuMonitorDispose(). Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-08 14:50:33 +00:00
virObjectUnref(xmlopt);
qemu: Kill processes used for QMP caps probing Since libvirt switched to QMP capabilities probing recently, it starts QEMU process used for this probing with -daemonize, which means virCommandAbort can no longer reach these processes. As a result of that, restarting libvirtd will leave several new QEMU processes behind. Let's use QEMU's -pidfile and use it to kill the process when QMP caps probing is done.
2012-10-02 08:59:56 +00:00
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
return ret;
qemu: Kill processes used for QMP caps probing Since libvirt switched to QMP capabilities probing recently, it starts QEMU process used for this probing with -daemonize, which means virCommandAbort can no longer reach these processes. As a result of that, restarting libvirtd will leave several new QEMU processes behind. Let's use QEMU's -pidfile and use it to kill the process when QMP caps probing is done.
2012-10-02 08:59:56 +00:00
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
ignore:
ret = 1;
goto cleanup;
}
Report original error when QMP probing fails with new QEMU If probing capabilities via QMP fails, we now have a check that prevents us falling back to -help parsing. Unfortunately the error message "Failed to probe capabilities for /usr/bin/qemu-kvm: unsupported configuration: QEMU 2.1.2 is too new for help parsing" is proving rather unhelpful to the user. We need to be telling them why QMP failed (the root cause), rather than they can't use -help (the side effect). To do this we should capture stderr during QMP probing, and if -help parsing then sees a new QEMU version, we know that QMP should have worked, and so we can show the messages from stderr. The message thus becomes "Failed to probe capabilities for /usr/bin/qemu-kvm: internal error: QEMU / QMP failed: Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory"
2014-12-04 15:26:41 +00:00
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
static int
virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
const char *libDir,
uid_t runUid,
gid_t runGid,
char **qmperr)
{
virQEMUCapsInitQMPCommandPtr cmd = NULL;
int ret = -1;
int rc;
if (!(cmd = virQEMUCapsInitQMPCommandNew(qemuCaps->binary, libDir,
runUid, runGid, qmperr)))
goto cleanup;
qemu: Enable KVM when probing capabilities CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities: QEMU_CAPS_KVM is set QEMU_CAPS_ENABLE_KVM is not set - TCG was used and QEMU supports KVM, but it failed (e.g., missing kernel module or wrong /dev/kvm permissions) QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is set - KVM was not used and QEMU does not support it QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is not set Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 15:16:21 +00:00
if ((rc = virQEMUCapsInitQMPCommandRun(cmd, false)) != 0) {
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
if (rc == 1)
ret = 0;
goto cleanup;
qemu: Kill processes used for QMP caps probing Since libvirt switched to QMP capabilities probing recently, it starts QEMU process used for this probing with -daemonize, which means virCommandAbort can no longer reach these processes. As a result of that, restarting libvirtd will leave several new QEMU processes behind. Let's use QEMU's -pidfile and use it to kill the process when QMP caps probing is done.
2012-10-02 08:59:56 +00:00
}
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
if (virQEMUCapsInitQMPMonitor(qemuCaps, cmd->mon) < 0)
goto cleanup;
qemu: Enable KVM when probing capabilities CPU related capabilities may differ depending on accelerator used when probing. Let's use KVM if available when probing QEMU and fall back to TCG. The created capabilities already contain all we need to distinguish whether KVM or TCG was used: - KVM was used when probing capabilities: QEMU_CAPS_KVM is set QEMU_CAPS_ENABLE_KVM is not set - TCG was used and QEMU supports KVM, but it failed (e.g., missing kernel module or wrong /dev/kvm permissions) QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is set - KVM was not used and QEMU does not support it QEMU_CAPS_KVM is not set QEMU_CAPS_ENABLE_KVM is not set Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-10 15:16:21 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
virQEMUCapsInitQMPCommandAbort(cmd);
if ((rc = virQEMUCapsInitQMPCommandRun(cmd, true)) != 0) {
if (rc == 1)
ret = 0;
goto cleanup;
}
if (virQEMUCapsInitQMPMonitorTCG(qemuCaps, cmd->mon) < 0)
goto cleanup;
}
qemu: Make QMP probing process reusable The code that runs a new QEMU process to be used for probing capabilities is separated into four reusable functions so that any code that wants to probe a QEMU process may just follow a few simple steps: cmd = virQEMUCapsInitQMPCommandNew(...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process using its QMP monitor */ if (reprobeIsRequired) { virQEMUCapsInitQMPCommandAbort(cmd, ...); virQEMUCapsInitQMPCommandRun(cmd); /* talk to the running QEMU process again */ } virQEMUCapsInitQMPCommandFree(cmd); Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2013-07-22 17:38:37 +00:00
ret = 0;
cleanup:
virQEMUCapsInitQMPCommandFree(cmd);
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
return ret;
}
Generate a unique journald log for QEMU capabilities failure When probing QEMU capabilities fails for a binary generate a log message with MESSAGE_ID==8ae2f3fb-2dbe-498e-8fbd-012d40afa361. This can be directly queried from journald based on the UUID instead of needing string grep. This lets tools like libguestfs' bug reporting tool trivially do automated sanity tests on the host they're running on. $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361 Feb 21 17:11:01 localhost.localdomain lt-libvirtd[9196]: Failed to probe capabilities for /bin/qemu-system-alpha: internal error: Child process (LC_ALL=C LD_LIBRARY_PATH= /home/berrange/src/virt/libvirt/src/.libs PATH=/usr/lib64/ ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin: /usr/bin:/root/bin HOME=/root USER=root LOGNAME=root /bin/qemu-system-alpha -help) unexpected exit status 127: /bin/qemu-system-alpha: error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361 --output=json { ...snip... "LIBVIRT_SOURCE" : "file", "PRIORITY" : "3", "CODE_FILE" : "qemu/qemu_capabilities.c", "CODE_LINE" : "2770", "CODE_FUNC" : "virQEMUCapsLogProbeFailure", "MESSAGE_ID" : "8ae2f3fb-2dbe-498e-8fbd-012d40afa361", "LIBVIRT_QEMU_BINARY" : "/bin/qemu-system-xtensa", "MESSAGE" : "Failed to probe capabilities for /bin/qemu-system-xtensa: internal error: Child process (LC_ALL=C LD_LIBRARY_PATH=/home/berrange /src/virt/libvirt/src/.libs PATH=/usr/lib64/ccache:/usr/local/sbin: /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin HOME=/root USER=root LOGNAME=root /bin/qemu-system-xtensa -help) unexpected exit status 127: /bin/qemu-system-xtensa: error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory\n" } Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-02-21 17:16:07 +00:00
#define MESSAGE_ID_CAPS_PROBE_FAILURE "8ae2f3fb-2dbe-498e-8fbd-012d40afa361"
static void
virQEMUCapsLogProbeFailure(const char *binary)
{
virLogMetadata meta[] = {
{ .key = "MESSAGE_ID", .s = MESSAGE_ID_CAPS_PROBE_FAILURE, .iv = 0 },
{ .key = "LIBVIRT_QEMU_BINARY", .s = binary, .iv = 0 },
{ .key = NULL },
};
Turn virLogSource into a struct instead of an enum As part of the goal to get away from doing string matching on filenames when deciding whether to emit a log message, turn the virLogSource enum into a struct which contains a log "name". There will eventually be one virLogSource instance statically declared per source file. To minimise churn in this commit though, a single global instance is used. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-02-27 17:44:53 +00:00
virLogMessage(&virLogSelf,
Generate a unique journald log for QEMU capabilities failure When probing QEMU capabilities fails for a binary generate a log message with MESSAGE_ID==8ae2f3fb-2dbe-498e-8fbd-012d40afa361. This can be directly queried from journald based on the UUID instead of needing string grep. This lets tools like libguestfs' bug reporting tool trivially do automated sanity tests on the host they're running on. $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361 Feb 21 17:11:01 localhost.localdomain lt-libvirtd[9196]: Failed to probe capabilities for /bin/qemu-system-alpha: internal error: Child process (LC_ALL=C LD_LIBRARY_PATH= /home/berrange/src/virt/libvirt/src/.libs PATH=/usr/lib64/ ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin: /usr/bin:/root/bin HOME=/root USER=root LOGNAME=root /bin/qemu-system-alpha -help) unexpected exit status 127: /bin/qemu-system-alpha: error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361 --output=json { ...snip... "LIBVIRT_SOURCE" : "file", "PRIORITY" : "3", "CODE_FILE" : "qemu/qemu_capabilities.c", "CODE_LINE" : "2770", "CODE_FUNC" : "virQEMUCapsLogProbeFailure", "MESSAGE_ID" : "8ae2f3fb-2dbe-498e-8fbd-012d40afa361", "LIBVIRT_QEMU_BINARY" : "/bin/qemu-system-xtensa", "MESSAGE" : "Failed to probe capabilities for /bin/qemu-system-xtensa: internal error: Child process (LC_ALL=C LD_LIBRARY_PATH=/home/berrange /src/virt/libvirt/src/.libs PATH=/usr/lib64/ccache:/usr/local/sbin: /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin HOME=/root USER=root LOGNAME=root /bin/qemu-system-xtensa -help) unexpected exit status 127: /bin/qemu-system-xtensa: error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory\n" } Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-02-21 17:16:07 +00:00
VIR_LOG_WARN,
__FILE__, __LINE__, __func__,
meta,
_("Failed to probe capabilities for %s: %s"),
qemu: Don't duplicate virGetLastErrorMessage These uses of virGetLastError message are just duplicating virGetLastErrorMessage.
2016-03-23 18:31:50 +00:00
binary, virGetLastErrorMessage());
Generate a unique journald log for QEMU capabilities failure When probing QEMU capabilities fails for a binary generate a log message with MESSAGE_ID==8ae2f3fb-2dbe-498e-8fbd-012d40afa361. This can be directly queried from journald based on the UUID instead of needing string grep. This lets tools like libguestfs' bug reporting tool trivially do automated sanity tests on the host they're running on. $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361 Feb 21 17:11:01 localhost.localdomain lt-libvirtd[9196]: Failed to probe capabilities for /bin/qemu-system-alpha: internal error: Child process (LC_ALL=C LD_LIBRARY_PATH= /home/berrange/src/virt/libvirt/src/.libs PATH=/usr/lib64/ ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin: /usr/bin:/root/bin HOME=/root USER=root LOGNAME=root /bin/qemu-system-alpha -help) unexpected exit status 127: /bin/qemu-system-alpha: error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361 --output=json { ...snip... "LIBVIRT_SOURCE" : "file", "PRIORITY" : "3", "CODE_FILE" : "qemu/qemu_capabilities.c", "CODE_LINE" : "2770", "CODE_FUNC" : "virQEMUCapsLogProbeFailure", "MESSAGE_ID" : "8ae2f3fb-2dbe-498e-8fbd-012d40afa361", "LIBVIRT_QEMU_BINARY" : "/bin/qemu-system-xtensa", "MESSAGE" : "Failed to probe capabilities for /bin/qemu-system-xtensa: internal error: Child process (LC_ALL=C LD_LIBRARY_PATH=/home/berrange /src/virt/libvirt/src/.libs PATH=/usr/lib64/ccache:/usr/local/sbin: /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin HOME=/root USER=root LOGNAME=root /bin/qemu-system-xtensa -help) unexpected exit status 127: /bin/qemu-system-xtensa: error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory\n" } Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-02-21 17:16:07 +00:00
}
qemu: Make virQEMUCapsNewForBinary usable from tests virQEMUCapsNewForBinary unconditionally loads data from cache and probes using both QMP and -help parsing, which is suboptimal when we want to use it in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-26 13:03:06 +00:00
virQEMUCapsPtr
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
virQEMUCapsNewForBinaryInternal(virArch hostArch,
qemu: Propagate virCapsPtr to virQEMUCapsNewForBinaryInternal Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 11:48:19 +00:00
const char *binary,
qemu: Make virQEMUCapsNewForBinary usable from tests virQEMUCapsNewForBinary unconditionally loads data from cache and probes using both QMP and -help parsing, which is suboptimal when we want to use it in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-26 13:03:06 +00:00
const char *libDir,
uid_t runUid,
gid_t runGid,
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
unsigned int microcodeVersion,
Force QMP capability probing Remove the qmpOnly argument of virQEMUCapsNewForBinaryInternal and instead always assume it's true. This effectively sets the minimum QEMU version to 1.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-03-28 20:46:41 +00:00
const char *kernelVersion)
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
{
qemu_capabilities: Resolve Coverity NULL_RETURNS Adjust the initialization of qemuCaps() to check for a NULL before attempting to dereference like other callers/users do.
2014-08-27 13:43:52 +00:00
virQEMUCapsPtr qemuCaps;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
struct stat sb;
Report original error when QMP probing fails with new QEMU If probing capabilities via QMP fails, we now have a check that prevents us falling back to -help parsing. Unfortunately the error message "Failed to probe capabilities for /usr/bin/qemu-kvm: unsupported configuration: QEMU 2.1.2 is too new for help parsing" is proving rather unhelpful to the user. We need to be telling them why QMP failed (the root cause), rather than they can't use -help (the side effect). To do this we should capture stderr during QMP probing, and if -help parsing then sees a new QEMU version, we know that QMP should have worked, and so we can show the messages from stderr. The message thus becomes "Failed to probe capabilities for /usr/bin/qemu-kvm: internal error: QEMU / QMP failed: Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory"
2014-12-04 15:26:41 +00:00
char *qmperr = NULL;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu_capabilities: Resolve Coverity NULL_RETURNS Adjust the initialization of qemuCaps() to check for a NULL before attempting to dereference like other callers/users do.
2014-08-27 13:43:52 +00:00
if (!(qemuCaps = virQEMUCapsNew()))
goto error;
Adapt to VIR_STRDUP and VIR_STRNDUP in src/qemu/*
2013-05-20 09:23:13 +00:00
if (VIR_STRDUP(qemuCaps->binary, binary) < 0)
goto error;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
/* We would also want to check faccessat if we cared about ACLs,
* but we don't. */
if (stat(binary, &sb) < 0) {
virReportSystemError(errno, _("Cannot check QEMU binary %s"),
binary);
goto error;
}
Change QEMU capabilities cache to check ctime instead of mtime Debian's package manager will preserve mtime timestamp on binaries from the time they are built, rather than installed. So if a user downgrades their QEMU dpkg, the libvirt capabilities cache will not refresh. The fix is to use ctime instead of mtime since it cannot be faked. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-10 15:50:19 +00:00
qemuCaps->ctime = sb.st_ctime;
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
/* Make sure the binary we are about to try exec'ing exists.
* Technically we could catch the exec() failure, but that's
* in a sub-process so it's hard to feed back a useful error.
*/
if (!virFileIsExecutable(binary)) {
virReportSystemError(errno, _("QEMU binary %s is not executable"),
binary);
goto error;
}
qemu: separate virQEMUCapsInitCached out of virQEMUCapsNewForBinaryInternal Preparation for switching to virFileCache where there are two callbacks, one to get a new data and second one to load a cached data. This also removes virQEMUCapsReset which is no longer required. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-18 14:14:07 +00:00
if (virQEMUCapsInitQMP(qemuCaps, libDir, runUid, runGid, &qmperr) < 0) {
virQEMUCapsLogProbeFailure(binary);
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
goto error;
qemu: separate virQEMUCapsInitCached out of virQEMUCapsNewForBinaryInternal Preparation for switching to virFileCache where there are two callbacks, one to get a new data and second one to load a cached data. This also removes virQEMUCapsReset which is no longer required. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-18 14:14:07 +00:00
}
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
Force QMP capability probing Remove the qmpOnly argument of virQEMUCapsNewForBinaryInternal and instead always assume it's true. This effectively sets the minimum QEMU version to 1.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-03-28 20:46:41 +00:00
if (!qemuCaps->usedQMP) {
qemu: separate virQEMUCapsInitCached out of virQEMUCapsNewForBinaryInternal Preparation for switching to virFileCache where there are two callbacks, one to get a new data and second one to load a cached data. This also removes virQEMUCapsReset which is no longer required. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-18 14:14:07 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to probe QEMU binary with QMP: %s"),
qmperr ? qmperr : _("unknown error"));
virQEMUCapsLogProbeFailure(binary);
goto error;
}
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
qemu: separate virQEMUCapsInitCached out of virQEMUCapsNewForBinaryInternal Preparation for switching to virFileCache where there are two callbacks, one to get a new data and second one to load a cached data. This also removes virQEMUCapsReset which is no longer required. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-18 14:14:07 +00:00
qemuCaps->libvirtCtime = virGetSelfLastChanged();
qemuCaps->libvirtVersion = LIBVIR_VERSION_NUMBER;
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsInitHostCPUModel(qemuCaps, hostArch, VIR_DOMAIN_VIRT_QEMU);
Add support for detecting capablities using QMP commands Start a QEMU process using $QEMU -S -no-user-config -nodefaults \ -nographic -M none -qmp unix:/some/path,server,nowait and talk QMP over stdio to discover what capabilities the binary supports. This works for QEMU 1.2.0 or later and for older QEMU automatically fallback to the old approach of parsing -help and related command line args. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 17:05:08 +00:00
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
qemuCaps->microcodeVersion = microcodeVersion;
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
if (VIR_STRDUP(qemuCaps->kernelVersion, kernelVersion) < 0)
goto error;
}
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
cleanup:
Report original error when QMP probing fails with new QEMU If probing capabilities via QMP fails, we now have a check that prevents us falling back to -help parsing. Unfortunately the error message "Failed to probe capabilities for /usr/bin/qemu-kvm: unsupported configuration: QEMU 2.1.2 is too new for help parsing" is proving rather unhelpful to the user. We need to be telling them why QMP failed (the root cause), rather than they can't use -help (the side effect). To do this we should capture stderr during QMP probing, and if -help parsing then sees a new QEMU version, we know that QMP should have worked, and so we can show the messages from stderr. The message thus becomes "Failed to probe capabilities for /usr/bin/qemu-kvm: internal error: QEMU / QMP failed: Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory"
2014-12-04 15:26:41 +00:00
VIR_FREE(qmperr);
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
return qemuCaps;
Introduce a API for creating QEMU capabilities for a binary Introduce a qemuCapsNewForBinary() API which creates a new QEMU capabilities object, populated with data relating to a specific QEMU binary. The qemuCaps object is also given a timestamp, which makes it possible to detect when the cached capabilities for a binary are out of date Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-10 10:47:56 +00:00
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
error:
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virObjectUnref(qemuCaps);
qemuCaps = NULL;
qemu: Store host-model CPU in qemu capabilities Host capabilities provide libvirt's view of the host CPU, but for a useful support for host-model CPUs we really need a hypervisor's view of the CPU. And since the view can be differ with emulator, qemu capabilities is the best place to store the host CPU model. This patch just copies the CPU model from host capabilities, but this will change in the future. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 12:35:18 +00:00
goto cleanup;
Introduce a API for creating QEMU capabilities for a binary Introduce a qemuCapsNewForBinary() API which creates a new QEMU capabilities object, populated with data relating to a specific QEMU binary. The qemuCaps object is also given a timestamp, which makes it possible to detect when the cached capabilities for a binary are out of date Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-10 10:47:56 +00:00
}
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
static void *
virQEMUCapsNewData(const char *binary,
void *privData)
qemu: Make virQEMUCapsNewForBinary usable from tests virQEMUCapsNewForBinary unconditionally loads data from cache and probes using both QMP and -help parsing, which is suboptimal when we want to use it in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-26 13:03:06 +00:00
{
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsCachePrivPtr priv = privData;
return virQEMUCapsNewForBinaryInternal(priv->hostArch,
binary,
priv->libDir,
priv->runUid,
priv->runGid,
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
priv->microcodeVersion,
Force QMP capability probing Remove the qmpOnly argument of virQEMUCapsNewForBinaryInternal and instead always assume it's true. This effectively sets the minimum QEMU version to 1.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-03-28 20:46:41 +00:00
priv->kernelVersion);
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
}
qemu: separate virQEMUCapsInitCached out of virQEMUCapsNewForBinaryInternal Preparation for switching to virFileCache where there are two callbacks, one to get a new data and second one to load a cached data. This also removes virQEMUCapsReset which is no longer required. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-18 14:14:07 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
static void *
virQEMUCapsLoadFile(const char *filename,
const char *binary,
void *privData)
{
virQEMUCapsPtr qemuCaps = virQEMUCapsNew();
virQEMUCapsCachePrivPtr priv = privData;
qemu: separate virQEMUCapsInitCached out of virQEMUCapsNewForBinaryInternal Preparation for switching to virFileCache where there are two callbacks, one to get a new data and second one to load a cached data. This also removes virQEMUCapsReset which is no longer required. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-18 14:14:07 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
if (!qemuCaps)
return NULL;
qemu: separate virQEMUCapsInitCached out of virQEMUCapsNewForBinaryInternal Preparation for switching to virFileCache where there are two callbacks, one to get a new data and second one to load a cached data. This also removes virQEMUCapsReset which is no longer required. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-18 14:14:07 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
if (VIR_STRDUP(qemuCaps->binary, binary) < 0)
goto error;
if (virQEMUCapsLoadCache(priv->hostArch, qemuCaps, filename) < 0)
goto error;
cleanup:
qemu: separate virQEMUCapsInitCached out of virQEMUCapsNewForBinaryInternal Preparation for switching to virFileCache where there are two callbacks, one to get a new data and second one to load a cached data. This also removes virQEMUCapsReset which is no longer required. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-18 14:14:07 +00:00
return qemuCaps;
error:
virObjectUnref(qemuCaps);
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
qemuCaps = NULL;
goto cleanup;
qemu: Make virQEMUCapsNewForBinary usable from tests virQEMUCapsNewForBinary unconditionally loads data from cache and probes using both QMP and -help parsing, which is suboptimal when we want to use it in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-26 13:03:06 +00:00
}
Introduce a API for creating QEMU capabilities for a binary Introduce a qemuCapsNewForBinary() API which creates a new QEMU capabilities object, populated with data relating to a specific QEMU binary. The qemuCaps object is also given a timestamp, which makes it possible to detect when the cached capabilities for a binary are out of date Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-10 10:47:56 +00:00
virQEMUCapsCacheLookupCopy: Filter qemuCaps based on machineType Not all machine types support all devices, device properties, backends, etc. So until we create a matrix of [machineType, qemuCaps], lets just filter out some capabilities before we return them to the consumer (which is going to make decisions based on them straight away). Currently, as qemu is unable to tell which capabilities are (not) enabled for given machine types, it's us who has to hardcode the matrix. One day maybe the hardcoding will go away and we can create the matrix dynamically on the fly based on a few monitor calls. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-02-12 13:50:31 +00:00
struct virQEMUCapsMachineTypeFilter {
const char *machineType;
virQEMUCapsFlags *flags;
size_t nflags;
};
static const struct virQEMUCapsMachineTypeFilter virQEMUCapsMachineFilter[] = {
/* { "blah", virQEMUCapsMachineBLAHFilter,
ARRAY_CARDINALITY(virQEMUCapsMachineBLAHFilter) }, */
{ "", NULL, 0 },
};
void
virQEMUCapsFilterByMachineType(virQEMUCapsPtr qemuCaps,
const char *machineType)
{
size_t i;
if (!machineType)
return;
for (i = 0; i < ARRAY_CARDINALITY(virQEMUCapsMachineFilter); i++) {
const struct virQEMUCapsMachineTypeFilter *filter = &virQEMUCapsMachineFilter[i];
size_t j;
if (STRNEQ(filter->machineType, machineType))
continue;
for (j = 0; j < filter->nflags; j++)
virQEMUCapsClear(qemuCaps, filter->flags[j]);
}
qemu: capabilities: Extract availability of new cpu hotplug for machine types QEMU reports whether 'query-hotpluggable-cpus' is supported for a given machine type. Extract and cache the information using the capability cache. When copying the capabilities for a new start of qemu, mask out the presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type doesn't support hotpluggable cpus.
2016-07-29 07:45:19 +00:00
if (!virQEMUCapsGetMachineHotplugCpus(qemuCaps, machineType))
virQEMUCapsClear(qemuCaps, QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS);
virQEMUCapsCacheLookupCopy: Filter qemuCaps based on machineType Not all machine types support all devices, device properties, backends, etc. So until we create a matrix of [machineType, qemuCaps], lets just filter out some capabilities before we return them to the consumer (which is going to make decisions based on them straight away). Currently, as qemu is unable to tell which capabilities are (not) enabled for given machine types, it's us who has to hardcode the matrix. One day maybe the hardcoding will go away and we can create the matrix dynamically on the fly based on a few monitor calls. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-02-12 13:50:31 +00:00
}
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virFileCacheHandlers qemuCapsCacheHandlers = {
.isValid = virQEMUCapsIsValid,
.newData = virQEMUCapsNewData,
.loadFile = virQEMUCapsLoadFile,
.saveFile = virQEMUCapsSaveFile,
.privFree = virQEMUCapsCachePrivFree,
};
virFileCachePtr
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsCacheNew(const char *libDir,
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
const char *cacheDir,
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
uid_t runUid,
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
gid_t runGid,
unsigned int microcodeVersion)
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
{
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
char *capsCacheDir = NULL;
virFileCachePtr cache = NULL;
virQEMUCapsCachePrivPtr priv = NULL;
qemu: Don't initialize struct utsname It breaks the build and it is not really useful for anything. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2018-01-22 13:51:11 +00:00
struct utsname uts;
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
if (virAsprintf(&capsCacheDir, "%s/capabilities", cacheDir) < 0)
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
goto error;
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
if (!(cache = virFileCacheNew(capsCacheDir, "xml", &qemuCapsCacheHandlers)))
Cache result of QEMU capabilities extraction Extracting capabilities from QEMU takes a notable amount of time when all QEMU binaries are installed. Each system emulator needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds. This change causes the QEMU driver to save an XML file containing the content of the virQEMUCaps object instance in the cache dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml We attempt to load this and only if it fails, do we fallback to probing the QEMU binary. The ctime of the QEMU binary and libvirtd are stored in the cached file and its data discarded if either of them change. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2014-03-05 16:51:59 +00:00
goto error;
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
if (VIR_ALLOC(priv) < 0)
qemu: introduce struct _virQEMUCapsCachePriv This will store private data that will be used by following patches when switching to virFileCache. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-20 14:17:23 +00:00
goto error;
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virFileCacheSetPriv(cache, priv);
qemu: introduce struct _virQEMUCapsCachePriv This will store private data that will be used by following patches when switching to virFileCache. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-20 14:17:23 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
if (VIR_STRDUP(priv->libDir, libDir) < 0)
qemu: introduce struct _virQEMUCapsCachePriv This will store private data that will be used by following patches when switching to virFileCache. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-20 14:17:23 +00:00
goto error;
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
priv->hostArch = virArchFromHost();
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
priv->runUid = runUid;
priv->runGid = runGid;
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
priv->microcodeVersion = microcodeVersion;
qemu: Fix QMP Capabability Probing Failure QMP Capability probing will fail if QEMU cannot bind to the QMP monitor socket in the qemu_driver->libDir directory. That's because the child process is stripped of all capabilities and this directory is chown'ed to the configured QEMU user/group (normally qemu:qemu) by the QEMU driver. To prevent this from happening, the driver startup will now pass the QEMU uid and gid down to the capability probing code. All capability probing invocations of QEMU will be run with the configured QEMU uid instead of libvirtd's. Furter, the pid file handling is moved to libvirt, as QEMU cannot write to the qemu_driver->runDir (root:root). This also means that the libvirt daemonizing must be used. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
2012-11-26 14:17:13 +00:00
qemu: Refresh caps cache after booting a different kernel Whenever a different kernel is booted, some capabilities related to KVM (such as CPUID bits) may change. We need to refresh the cache to see the changes. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-22 10:37:04 +00:00
if (uname(&uts) == 0 &&
virAsprintf(&priv->kernelVersion, "%s %s", uts.release, uts.version) < 0)
goto error;
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
cleanup:
VIR_FREE(capsCacheDir);
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
return cache;
Indent top-level labels by one space in src/qemu/
2014-03-25 06:49:44 +00:00
error:
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virObjectUnref(cache);
cache = NULL;
goto cleanup;
qemu: Refactor virQEMUCapsCacheLookup The function is made a little bit more readable and the code which refreshes cached capabilities if they are not valid any more was moved into a separate function (virQEMUCapsCacheValidate) so that it can be reused in other places. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-16 12:47:09 +00:00
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsCacheLookup(virFileCachePtr cache,
qemu: Propagate virCapsPtr to virQEMUCapsNewForBinaryInternal Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-15 11:48:19 +00:00
const char *binary)
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
{
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr ret = NULL;
Implement infrastracture for mocking up QEMU capabilities cache The main purpose of this patch is to introduce test mode to virQEMUCapsCacheLookup(). This is done by adding a global variable, which effectively overrides binary name. This variable is supposed to be set by test suite. The second addition is qemuTestCapsCacheInsert() function which allows the test suite to actually populate the cache. Signed-off-by: Pavel Fedin <p.fedin@samsung.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2015-09-09 14:03:14 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
ret = virFileCacheLookup(cache, binary);
qemu: Refactor virQEMUCapsCacheLookup The function is made a little bit more readable and the code which refreshes cached capabilities if they are not valid any more was moved into a separate function (virQEMUCapsCacheValidate) so that it can be reused in other places. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-16 12:47:09 +00:00
VIR_DEBUG("Returning caps %p for %s", ret, binary);
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
return ret;
}
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsCacheLookupCopy(virFileCachePtr cache,
virQEMUCapsCacheLookupCopy: Pass machine type It will come handy in the near future when we will filter some capabilities based on it. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-02-12 12:48:42 +00:00
const char *binary,
virQEMUCapsCacheLookupCopy: Filter qemuCaps based on machineType Not all machine types support all devices, device properties, backends, etc. So until we create a matrix of [machineType, qemuCaps], lets just filter out some capabilities before we return them to the consumer (which is going to make decisions based on them straight away). Currently, as qemu is unable to tell which capabilities are (not) enabled for given machine types, it's us who has to hardcode the matrix. One day maybe the hardcoding will go away and we can create the matrix dynamically on the fly based on a few monitor calls. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-02-12 13:50:31 +00:00
const char *machineType)
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
{
qemu: pass only host arch instead of the whole virCaps This is a preparation for following patches where we switch to virFileCache for QEMU capabilities cache The host arch will always remain the same but virCaps may change. Now the host arch is stored while creating new qemu capabilities cache. It removes the need to pass virCaps into virQEMUCapsCache*() functions. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-21 13:09:54 +00:00
virQEMUCapsPtr qemuCaps = virQEMUCapsCacheLookup(cache, binary);
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
virQEMUCapsPtr ret;
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
if (!qemuCaps)
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
return NULL;
Rename 'qemuCapsXXX' to 'virQEMUCapsXXX' To avoid confusion between 'virCapsPtr' and 'qemuCapsPtr' do some renaming of various fucntions/variables. All instances of 'qemuCapsPtr' are renamed to 'qemuCaps'. To avoid that clashing with the 'qemuCaps' typedef though, rename the latter to virQEMUCaps. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-02-01 13:48:58 +00:00
ret = virQEMUCapsNewCopy(qemuCaps);
virObjectUnref(qemuCaps);
qemu: Check if virQEMUCapsNewCopy(...) has failed Check if virQEMUCapsNewCopy(...) has failed, thus a segmentation fault in virQEMUCapsFilterByMachineType(...) will be avoided. Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
2017-02-09 14:13:35 +00:00
if (!ret)
return NULL;
virQEMUCapsCacheLookupCopy: Filter qemuCaps based on machineType Not all machine types support all devices, device properties, backends, etc. So until we create a matrix of [machineType, qemuCaps], lets just filter out some capabilities before we return them to the consumer (which is going to make decisions based on them straight away). Currently, as qemu is unable to tell which capabilities are (not) enabled for given machine types, it's us who has to hardcode the matrix. One day maybe the hardcoding will go away and we can create the matrix dynamically on the fly based on a few monitor calls. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-02-12 13:50:31 +00:00
virQEMUCapsFilterByMachineType(ret, machineType);
Add a qemu capabilities cache manager Introduce a qemuCapsCachePtr object to provide a global cache of capabilities for QEMU binaries. The cache auto-populates on first request for capabilities about a binary, and will auto-refresh if the binary has changed since a previous cache was populated Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 12:54:13 +00:00
return ret;
}
qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch The API may come handy if somebody has an architecture and wants to look through available qemus if the architecture is supported or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:12:07 +00:00
static int
virQEMUCapsCompareArch(const void *payload,
const void *name ATTRIBUTE_UNUSED,
const void *opaque)
{
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
struct virQEMUCapsSearchData *data = (struct virQEMUCapsSearchData *)opaque;
qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch The API may come handy if somebody has an architecture and wants to look through available qemus if the architecture is supported or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:12:07 +00:00
const virQEMUCaps *qemuCaps = payload;
return qemuCaps->arch == data->arch;
}
virQEMUCapsPtr
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
virQEMUCapsCacheLookupByArch(virFileCachePtr cache,
qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch The API may come handy if somebody has an architecture and wants to look through available qemus if the architecture is supported or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:12:07 +00:00
virArch arch)
{
virQEMUCapsPtr ret = NULL;
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
virArch target;
qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch The API may come handy if somebody has an architecture and wants to look through available qemus if the architecture is supported or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:12:07 +00:00
struct virQEMUCapsSearchData data = { .arch = arch };
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
ret = virFileCacheLookupByFunc(cache, virQEMUCapsCompareArch, &data);
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
if (!ret) {
/* If the first attempt at finding capabilities has failed, try
* again using the QEMU target as lookup key instead */
target = virQEMUCapsFindTarget(virArchFromHost(), data.arch);
if (target != data.arch) {
data.arch = target;
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
ret = virFileCacheLookupByFunc(cache, virQEMUCapsCompareArch, &data);
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
}
}
qemu: Refresh caps in virQEMUCapsCacheLookupByArch The function just returned cached capabilities without checking whether they are still valid. We should check that and refresh the capabilities to make sure we don't return stale data. In other words, we should do what all other lookup functions do. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-16 13:17:12 +00:00
qemu: switch QEMU capabilities to use virFileCache The switch contains considerable amount of changes: virQEMUCapsRememberCached() is removed because this is now handled by virFileCacheSave(). virQEMUCapsInitCached() is removed because this is now handled by virFileCacheLoad(). virQEMUCapsNewForBinary() is split into two functions, virQEMUCapsNewData() which creates new data if there is nothing cached and virQEMUCapsLoadFile() which loads the cached data. This is now handled by virFileCacheNewData(). virQEMUCapsCacheValidate() is removed because this is now handled by virFileCacheValidate(). virQEMUCapsCacheFree() is removed because it's no longer required. Add virCapsPtr into virQEMUCapsCachePriv because for each call of virFileCacheLookup*() we need to use current virCapsPtr. Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-19 15:01:56 +00:00
if (!ret) {
qemu: Refresh caps in virQEMUCapsCacheLookupByArch The function just returned cached capabilities without checking whether they are still valid. We should check that and refresh the capabilities to make sure we don't return stale data. In other words, we should do what all other lookup functions do. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-16 13:17:12 +00:00
virReportError(VIR_ERR_INVALID_ARG,
_("unable to find any emulator to serve '%s' "
"architecture"), virArchToString(arch));
}
qemu: Fix using guest architecture as lookup key When looking for a QEMU binary suitable for running ppc64le guests we have to take into account the fact that we use the QEMU target as key for the hash, so direct comparison is not good enough. Factor out the logic from virQEMUCapsFindBinaryForArch() to a new virQEMUCapsFindTarget() function and use that both when looking for QEMU binaries available on the system and when looking up QEMU capabilities later. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260753
2015-09-15 13:58:09 +00:00
VIR_DEBUG("Returning caps %p for arch %s", ret, virArchToString(arch));
qemu_capabilities: Introduce virQEMUCapsCacheLookupByArch The API may come handy if somebody has an architecture and wants to look through available qemus if the architecture is supported or not. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:12:07 +00:00
return ret;
}
qemu_capabilities: Introduce virQEMUCapsCacheLookupDefault virConnectGetDomainCapabilities needs to lookup QEMU capabilities matching a specified binary, architecture, virt type, and machine type while using default values when any of the parameters are not provided by the user. Let's extract the lookup code into virQEMUCapsCacheLookupDefault to make it reusable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-07 20:51:57 +00:00
/**
* virQEMUCapsCacheLookupDefault:
* @cache: QEMU capabilities cache
* @binary: optional path to QEMU binary
* @archStr: optional guest architecture
* @virttypeStr: optional virt type
* @machine: optional machine type
* @retArch: if non-NULL, guest architecture will be returned here
* @retVirttype: if non-NULL, domain virt type will be returned here
* @retMachine: if non-NULL, canonical machine type will be returned here
*
* Looks up the QEMU binary specified by @binary and @archStr, checks it can
* provide the required @virttypeStr and @machine and returns its capabilities.
* Sensible defaults are used for any argument which is NULL (the function can
* even be called with all NULL arguments).
*
* Returns QEMU capabilities matching the requirements, NULL on error.
*/
virQEMUCapsPtr
virQEMUCapsCacheLookupDefault(virFileCachePtr cache,
const char *binary,
const char *archStr,
const char *virttypeStr,
const char *machine,
virArch *retArch,
virDomainVirtType *retVirttype,
const char **retMachine)
{
int virttype = VIR_DOMAIN_VIRT_NONE;
int arch = virArchFromHost();
virDomainVirtType capsType;
virQEMUCapsPtr qemuCaps = NULL;
virQEMUCapsPtr ret = NULL;
if (virttypeStr &&
(virttype = virDomainVirtTypeFromString(virttypeStr)) < 0) {
virReportError(VIR_ERR_INVALID_ARG,
_("unknown virttype: %s"), virttypeStr);
goto cleanup;
}
if (archStr &&
(arch = virArchFromString(archStr)) == VIR_ARCH_NONE) {
virReportError(VIR_ERR_INVALID_ARG,
_("unknown architecture: %s"), archStr);
goto cleanup;
}
if (binary) {
virArch arch_from_caps;
if (!(qemuCaps = virQEMUCapsCacheLookup(cache, binary)))
goto cleanup;
arch_from_caps = virQEMUCapsGetArch(qemuCaps);
if (arch_from_caps != arch &&
!((ARCH_IS_X86(arch) && ARCH_IS_X86(arch_from_caps)) ||
(ARCH_IS_PPC(arch) && ARCH_IS_PPC(arch_from_caps)) ||
(ARCH_IS_ARM(arch) && ARCH_IS_ARM(arch_from_caps)) ||
(ARCH_IS_S390(arch) && ARCH_IS_S390(arch_from_caps)))) {
virReportError(VIR_ERR_INVALID_ARG,
_("architecture from emulator '%s' doesn't "
"match given architecture '%s'"),
virArchToString(arch_from_caps),
virArchToString(arch));
goto cleanup;
}
} else {
if (!(qemuCaps = virQEMUCapsCacheLookupByArch(cache, arch)))
goto cleanup;
binary = virQEMUCapsGetBinary(qemuCaps);
}
if (machine) {
/* Turn @machine into canonical name */
machine = virQEMUCapsGetCanonicalMachine(qemuCaps, machine);
if (!virQEMUCapsIsMachineSupported(qemuCaps, machine)) {
virReportError(VIR_ERR_INVALID_ARG,
_("the machine '%s' is not supported by emulator '%s'"),
machine, binary);
goto cleanup;
}
} else {
qemu: rename method for getting preferred machine type The virQEMUCapsGetDefaultMachine() method doesn't get QEMU's default machine any more, instead it gets the historical default that libvirt prefers for each arch. Rename it, so that the old name can be used for getting QEMU's default. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 14:06:38 +00:00
machine = virQEMUCapsGetPreferredMachine(qemuCaps);
qemu_capabilities: Introduce virQEMUCapsCacheLookupDefault virConnectGetDomainCapabilities needs to lookup QEMU capabilities matching a specified binary, architecture, virt type, and machine type while using default values when any of the parameters are not provided by the user. Let's extract the lookup code into virQEMUCapsCacheLookupDefault to make it reusable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-07 20:51:57 +00:00
}
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
capsType = VIR_DOMAIN_VIRT_KVM;
else
capsType = VIR_DOMAIN_VIRT_QEMU;
if (virttype == VIR_DOMAIN_VIRT_NONE)
virttype = capsType;
if (virttype == VIR_DOMAIN_VIRT_KVM && capsType == VIR_DOMAIN_VIRT_QEMU) {
virReportError(VIR_ERR_INVALID_ARG,
_("KVM is not supported by '%s' on this host"),
binary);
goto cleanup;
}
if (retArch)
*retArch = arch;
if (retVirttype)
*retVirttype = virttype;
if (retMachine)
*retMachine = machine;
VIR_STEAL_PTR(ret, qemuCaps);
cleanup:
virObjectUnref(qemuCaps);
return ret;
}
qemu: add virQEMUCapsSupportsVmport The vmport machine argument works with pc machine kind, not with xen for example.
2015-04-21 11:28:40 +00:00
bool
virQEMUCapsSupportsVmport(virQEMUCapsPtr qemuCaps,
const virDomainDef *def)
{
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_MACHINE_VMPORT_OPT))
return false;
qemu: refactor qemuDomainMachine* functions Introduce new wrapper functions without *Machine* in the function name that take the whole virDomainDef structure as argument and call the existing functions with *Machine* in the function name. Change the arguments of existing functions to *machine* and *arch* because they don't need the whole virDomainDef structure and they could be used in places where we don't have virDomainDef. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-18 10:43:58 +00:00
return qemuDomainIsI440FX(def) ||
qemuDomainIsQ35(def) ||
qemu: add virQEMUCapsSupportsVmport The vmport machine argument works with pc machine kind, not with xen for example.
2015-04-21 11:28:40 +00:00
STREQ(def->os.machine, "isapc");
}
qemu_capabilities: Introduce virQEMUCapsIsMachineSupported This internal API is meant to answer the question 'Is this machine type supported by given qemu?'. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:31:51 +00:00
bool
virQEMUCapsIsMachineSupported(virQEMUCapsPtr qemuCaps,
const char *canonical_machine)
{
size_t i;
for (i = 0; i < qemuCaps->nmachineTypes; i++) {
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
if (STREQ(canonical_machine, qemuCaps->machineTypes[i].name))
qemu_capabilities: Introduce virQEMUCapsIsMachineSupported This internal API is meant to answer the question 'Is this machine type supported by given qemu?'. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:31:51 +00:00
return true;
}
return false;
}
qemu_capabilities: Introduce virQEMUCapsGetDefaultMachine Sometimes it may be useful to get a default machine for given qemu binary. Fortunately, the default machine is stored always on the first position in the supported machines array. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:39:18 +00:00
qemu: rename method for getting preferred machine type The virQEMUCapsGetDefaultMachine() method doesn't get QEMU's default machine any more, instead it gets the historical default that libvirt prefers for each arch. Rename it, so that the old name can be used for getting QEMU's default. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 14:06:38 +00:00
/*
* The preferred machine to use if none is listed explicitly
* Note that this may differ from QEMU's own default machine
*/
qemu_capabilities: Introduce virQEMUCapsGetDefaultMachine Sometimes it may be useful to get a default machine for given qemu binary. Fortunately, the default machine is stored always on the first position in the supported machines array. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:39:18 +00:00
const char *
qemu: rename method for getting preferred machine type The virQEMUCapsGetDefaultMachine() method doesn't get QEMU's default machine any more, instead it gets the historical default that libvirt prefers for each arch. Rename it, so that the old name can be used for getting QEMU's default. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-08-10 14:06:38 +00:00
virQEMUCapsGetPreferredMachine(virQEMUCapsPtr qemuCaps)
qemu_capabilities: Introduce virQEMUCapsGetDefaultMachine Sometimes it may be useful to get a default machine for given qemu binary. Fortunately, the default machine is stored always on the first position in the supported machines array. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:39:18 +00:00
{
if (!qemuCaps->nmachineTypes)
return NULL;
qemu: caps: Sanitize storage of machine type related data Add a structure to store the data and use a single array of the structures rather than having 3 separate arrays with shared indexes.
2016-07-29 08:13:46 +00:00
return qemuCaps->machineTypes[0].name;
qemu_capabilities: Introduce virQEMUCapsGetDefaultMachine Sometimes it may be useful to get a default machine for given qemu binary. Fortunately, the default machine is stored always on the first position in the supported machines array. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-30 14:39:18 +00:00
}
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
static int
qemu: always assume QEMU_CAPS_DRIVE_READONLY We have been always setting the capability on if qemu has QEMU_CAPS_DEVICE.
2016-05-20 11:29:54 +00:00
virQEMUCapsFillDomainLoaderCaps(virDomainCapsLoaderPtr capsLoader,
driver config: Introduce virFirmware object The virQEMUDriverConfig object contains lists of loader:nvram pairs to advertise firmwares supported by by the driver, and qemu_conf.c contains code to populate the lists, all of which is useful for other drivers too. To avoid code duplication, introduce a virFirmware object to encapsulate firmware details and switch the qemu driver to use it. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-17 22:45:27 +00:00
virFirmwarePtr *firmwares,
size_t nfirmwares)
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
{
domaincaps: Expose UEFI binary path, if it exists Check to see if the UEFI binary mentioned in qemu.conf actually exists, and if so expose it in domcapabilities like <loader ...> <value>/path/to/ovmf</value> </loader> We introduce some generic domcaps infrastructure for handling a dynamic list of string values, it may be of use for future bits. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 23:52:54 +00:00
size_t i;
conf: Get rid of virDomainCapsDevice The struct contains a single boolean field, 'supported': the meaning of this field is too generic to be limited to devices only, and in fact it's already being used for other things like loaders and OSs. Instead of trying to come up with a more generic name just get rid of the struct altogether.
2016-03-10 18:52:52 +00:00
capsLoader->supported = true;
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
driver config: Introduce virFirmware object The virQEMUDriverConfig object contains lists of loader:nvram pairs to advertise firmwares supported by by the driver, and qemu_conf.c contains code to populate the lists, all of which is useful for other drivers too. To avoid code duplication, introduce a virFirmware object to encapsulate firmware details and switch the qemu driver to use it. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-17 22:45:27 +00:00
if (VIR_ALLOC_N(capsLoader->values.values, nfirmwares) < 0)
domaincaps: Expose UEFI binary path, if it exists Check to see if the UEFI binary mentioned in qemu.conf actually exists, and if so expose it in domcapabilities like <loader ...> <value>/path/to/ovmf</value> </loader> We introduce some generic domcaps infrastructure for handling a dynamic list of string values, it may be of use for future bits. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 23:52:54 +00:00
return -1;
driver config: Introduce virFirmware object The virQEMUDriverConfig object contains lists of loader:nvram pairs to advertise firmwares supported by by the driver, and qemu_conf.c contains code to populate the lists, all of which is useful for other drivers too. To avoid code duplication, introduce a virFirmware object to encapsulate firmware details and switch the qemu driver to use it. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-17 22:45:27 +00:00
for (i = 0; i < nfirmwares; i++) {
const char *filename = firmwares[i]->name;
domaincaps: Expose UEFI binary path, if it exists Check to see if the UEFI binary mentioned in qemu.conf actually exists, and if so expose it in domcapabilities like <loader ...> <value>/path/to/ovmf</value> </loader> We introduce some generic domcaps infrastructure for handling a dynamic list of string values, it may be of use for future bits. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 23:52:54 +00:00
if (!virFileExists(filename)) {
VIR_DEBUG("loader filename=%s does not exist", filename);
continue;
}
Fix build in qemu_capabilities Commit f05b6a91 added virQEMUDriverConfigPtr argument to the virQEMUCapsFillDomainCaps function and it uses forward declaration of virQEMUDriverConfig and virQEMUDriverConfigPtr that casues clang build to fail: gmake[3]: Entering directory `/usr/home/novel/code/libvirt/src' CC qemu/libvirt_driver_qemu_impl_la-qemu_capabilities.lo In file included from qemu/qemu_capabilities.c:43: In file included from qemu/qemu_hostdev.h:27: qemu/qemu_conf.h:63:37: error: redefinition of typedef 'virQEMUDriverConfig' is a C11 feature [-Werror,-Wtypedef-redefinition] typedef struct _virQEMUDriverConfig virQEMUDriverConfig; ^ qemu/qemu_capabilities.h:328:37: note: previous definition is here typedef struct _virQEMUDriverConfig virQEMUDriverConfig; ^ Fix that by passing loader and nloader config attributes directly instead of passing complete config.
2014-09-18 06:30:40 +00:00
if (VIR_STRDUP(capsLoader->values.values[capsLoader->values.nvalues],
domaincaps: Expose UEFI binary path, if it exists Check to see if the UEFI binary mentioned in qemu.conf actually exists, and if so expose it in domcapabilities like <loader ...> <value>/path/to/ovmf</value> </loader> We introduce some generic domcaps infrastructure for handling a dynamic list of string values, it may be of use for future bits. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 23:52:54 +00:00
filename) < 0)
return -1;
Fix build in qemu_capabilities Commit f05b6a91 added virQEMUDriverConfigPtr argument to the virQEMUCapsFillDomainCaps function and it uses forward declaration of virQEMUDriverConfig and virQEMUDriverConfigPtr that casues clang build to fail: gmake[3]: Entering directory `/usr/home/novel/code/libvirt/src' CC qemu/libvirt_driver_qemu_impl_la-qemu_capabilities.lo In file included from qemu/qemu_capabilities.c:43: In file included from qemu/qemu_hostdev.h:27: qemu/qemu_conf.h:63:37: error: redefinition of typedef 'virQEMUDriverConfig' is a C11 feature [-Werror,-Wtypedef-redefinition] typedef struct _virQEMUDriverConfig virQEMUDriverConfig; ^ qemu/qemu_capabilities.h:328:37: note: previous definition is here typedef struct _virQEMUDriverConfig virQEMUDriverConfig; ^ Fix that by passing loader and nloader config attributes directly instead of passing complete config.
2014-09-18 06:30:40 +00:00
capsLoader->values.nvalues++;
domaincaps: Expose UEFI binary path, if it exists Check to see if the UEFI binary mentioned in qemu.conf actually exists, and if so expose it in domcapabilities like <loader ...> <value>/path/to/ovmf</value> </loader> We introduce some generic domcaps infrastructure for handling a dynamic list of string values, it may be of use for future bits. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 23:52:54 +00:00
}
Fix build in qemu_capabilities Commit f05b6a91 added virQEMUDriverConfigPtr argument to the virQEMUCapsFillDomainCaps function and it uses forward declaration of virQEMUDriverConfig and virQEMUDriverConfigPtr that casues clang build to fail: gmake[3]: Entering directory `/usr/home/novel/code/libvirt/src' CC qemu/libvirt_driver_qemu_impl_la-qemu_capabilities.lo In file included from qemu/qemu_capabilities.c:43: In file included from qemu/qemu_hostdev.h:27: qemu/qemu_conf.h:63:37: error: redefinition of typedef 'virQEMUDriverConfig' is a C11 feature [-Werror,-Wtypedef-redefinition] typedef struct _virQEMUDriverConfig virQEMUDriverConfig; ^ qemu/qemu_capabilities.h:328:37: note: previous definition is here typedef struct _virQEMUDriverConfig virQEMUDriverConfig; ^ Fix that by passing loader and nloader config attributes directly instead of passing complete config.
2014-09-18 06:30:40 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(capsLoader->type,
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
VIR_DOMAIN_LOADER_TYPE_ROM);
qemu: assume -drive format is always available As of QEMU 0.10.0 the -drive format= parameter was added, so the QEMU driver can assume it is always available. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-06 18:20:20 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(capsLoader->type,
VIR_DOMAIN_LOADER_TYPE_PFLASH);
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
qemu: always assume QEMU_CAPS_DRIVE_READONLY We have been always setting the capability on if qemu has QEMU_CAPS_DEVICE.
2016-05-20 11:29:54 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(capsLoader->readonly,
VIR_TRISTATE_BOOL_YES,
VIR_TRISTATE_BOOL_NO);
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
return 0;
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
}
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
static int
qemu: always assume QEMU_CAPS_DRIVE_READONLY We have been always setting the capability on if qemu has QEMU_CAPS_DEVICE.
2016-05-20 11:29:54 +00:00
virQEMUCapsFillDomainOSCaps(virDomainCapsOSPtr os,
driver config: Introduce virFirmware object The virQEMUDriverConfig object contains lists of loader:nvram pairs to advertise firmwares supported by by the driver, and qemu_conf.c contains code to populate the lists, all of which is useful for other drivers too. To avoid code duplication, introduce a virFirmware object to encapsulate firmware details and switch the qemu driver to use it. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-17 22:45:27 +00:00
virFirmwarePtr *firmwares,
size_t nfirmwares)
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
{
Fix build in qemu_capabilities Commit f05b6a91 added virQEMUDriverConfigPtr argument to the virQEMUCapsFillDomainCaps function and it uses forward declaration of virQEMUDriverConfig and virQEMUDriverConfigPtr that casues clang build to fail: gmake[3]: Entering directory `/usr/home/novel/code/libvirt/src' CC qemu/libvirt_driver_qemu_impl_la-qemu_capabilities.lo In file included from qemu/qemu_capabilities.c:43: In file included from qemu/qemu_hostdev.h:27: qemu/qemu_conf.h:63:37: error: redefinition of typedef 'virQEMUDriverConfig' is a C11 feature [-Werror,-Wtypedef-redefinition] typedef struct _virQEMUDriverConfig virQEMUDriverConfig; ^ qemu/qemu_capabilities.h:328:37: note: previous definition is here typedef struct _virQEMUDriverConfig virQEMUDriverConfig; ^ Fix that by passing loader and nloader config attributes directly instead of passing complete config.
2014-09-18 06:30:40 +00:00
virDomainCapsLoaderPtr capsLoader = &os->loader;
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
conf: Get rid of virDomainCapsDevice The struct contains a single boolean field, 'supported': the meaning of this field is too generic to be limited to devices only, and in fact it's already being used for other things like loaders and OSs. Instead of trying to come up with a more generic name just get rid of the struct altogether.
2016-03-10 18:52:52 +00:00
os->supported = true;
driver config: Introduce virFirmware object The virQEMUDriverConfig object contains lists of loader:nvram pairs to advertise firmwares supported by by the driver, and qemu_conf.c contains code to populate the lists, all of which is useful for other drivers too. To avoid code duplication, introduce a virFirmware object to encapsulate firmware details and switch the qemu driver to use it. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-17 22:45:27 +00:00
if (virQEMUCapsFillDomainLoaderCaps(capsLoader, firmwares, nfirmwares) < 0)
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
return -1;
return 0;
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
}
qemu: Fill in CPU domain capabilities Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-22 20:22:30 +00:00
static int
virQEMUCapsFillDomainCPUCaps(virCapsPtr caps,
virQEMUCapsPtr qemuCaps,
virDomainCapsPtr domCaps)
{
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
if (virQEMUCapsIsCPUModeSupported(qemuCaps, caps, domCaps->virttype,
VIR_CPU_MODE_HOST_PASSTHROUGH))
qemu: Fill in CPU domain capabilities Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-22 20:22:30 +00:00
domCaps->cpu.hostPassthrough = true;
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
if (virQEMUCapsIsCPUModeSupported(qemuCaps, caps, domCaps->virttype,
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
VIR_CPU_MODE_HOST_MODEL)) {
qemu: Prepare qemuCaps for multiple host CPU defs Soon we will need to store multiple host CPU definitions in virQEMUCapsHostCPUData and qemuCaps users will want to request the one they need. This patch introduces virQEMUCapsHostCPUType enum which will be used for specifying the requested CPU definition. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-11 09:14:30 +00:00
virCPUDefPtr cpu = virQEMUCapsGetHostModel(qemuCaps, domCaps->virttype,
VIR_QEMU_CAPS_HOST_CPU_REPORTED);
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 15:51:50 +00:00
domCaps->cpu.hostModel = virCPUDefCopy(cpu);
}
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
if (virQEMUCapsIsCPUModeSupported(qemuCaps, caps, domCaps->virttype,
VIR_CPU_MODE_CUSTOM)) {
virDomainCapsCPUModelsPtr filtered = NULL;
char **models = NULL;
qemu: Avoid reporting "host" as a supported CPU model "host" CPU model is supported by a special host-passthrough CPU mode and users is not allowed to specify this model directly with custom mode. Thus we should not advertise "host" CPU model in domain capabilities. This worked well on architectures for which libvirt provides a list of supported CPU models in cpu_map.xml (since "host" is not in the list). But we need to explicitly filter "host" model out for all other architectures. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-20 22:21:19 +00:00
const char *blacklist[] = { "host", NULL };
qemu: Fill in CPU domain capabilities Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-22 20:22:30 +00:00
cpu: Rename cpuGetModels The new name is virCPUGetModels. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-04 13:20:39 +00:00
if (virCPUGetModels(domCaps->arch, &models) >= 0) {
qemu: Probe CPU models for KVM and TCG CPU models (and especially some additional details which we will start probing for later) differ depending on the accelerator. Thus we need to call query-cpu-definitions in both KVM and TCG mode to get all data we want. Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid having to squash even more stuff into this single patch. They will all be switched back later in separate commits. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-14 16:21:30 +00:00
virDomainCapsCPUModelsPtr cpus;
if (domCaps->virttype == VIR_DOMAIN_VIRT_KVM)
cpus = qemuCaps->kvmCPUModels;
else
cpus = qemuCaps->tcgCPUModels;
filtered = virDomainCapsCPUModelsFilter(cpus,
qemu/: Remove spaces after casts Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-04-25 12:42:34 +00:00
(const char **)models,
qemu: Avoid reporting "host" as a supported CPU model "host" CPU model is supported by a special host-passthrough CPU mode and users is not allowed to specify this model directly with custom mode. Thus we should not advertise "host" CPU model in domain capabilities. This worked well on architectures for which libvirt provides a list of supported CPU models in cpu_map.xml (since "host" is not in the list). But we need to explicitly filter "host" model out for all other architectures. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-20 22:21:19 +00:00
blacklist);
virstring: Unify string list function names We have couple of functions that operate over NULL terminated lits of strings. However, our naming sucks: virStringJoin virStringFreeList virStringFreeListCount virStringArrayHasString virStringGetFirstWithPrefix We can do better: virStringListJoin virStringListFree virStringListFreeCount virStringListHasString virStringListGetFirstWithPrefix Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-11-25 08:18:35 +00:00
virStringListFree(models);
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
}
domCaps->cpu.custom = filtered;
domcaps: Show only CPU models supported by libvirt Listing all CPU models supported by QEMU in domain capabilities makes little sense when libvirt will refuse any model it doesn't know about. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-29 08:42:56 +00:00
}
qemu: Fill in CPU domain capabilities Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-22 20:22:30 +00:00
return 0;
}
qemu: Add I/O thread support info into domain capabilities Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-10-19 12:19:38 +00:00
static int
virQEMUCapsFillDomainIOThreadCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsPtr domCaps)
{
domCaps->iothreads = virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_IOTHREAD);
return 0;
}
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
static int
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
virQEMUCapsFillDomainDeviceDiskCaps(virQEMUCapsPtr qemuCaps,
Caps: Disable floppy disk for PowerPC VM PowerPC pseries based VMs do not support a floppy disk controller. This prohibits libvirt from adding floppy disk for a PowerPC pseries VM. Signed-off-by: Kothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
2015-07-30 11:54:26 +00:00
const char *machine,
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
virDomainCapsDeviceDiskPtr disk)
{
conf: Get rid of virDomainCapsDevice The struct contains a single boolean field, 'supported': the meaning of this field is too generic to be limited to devices only, and in fact it's already being used for other things like loaders and OSs. Instead of trying to come up with a more generic name just get rid of the struct altogether.
2016-03-10 18:52:52 +00:00
disk->supported = true;
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
/* QEMU supports all of these */
VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice,
VIR_DOMAIN_DISK_DEVICE_DISK,
qemu: Drop QEMU_CAPS_VIRTIO_BLK_SG_IO The only QEMU versions that don't have such capability are <0.11, which we no longer support anyway
2016-05-16 08:29:57 +00:00
VIR_DOMAIN_DISK_DEVICE_CDROM,
VIR_DOMAIN_DISK_DEVICE_LUN);
Caps: Disable floppy disk for PowerPC VM PowerPC pseries based VMs do not support a floppy disk controller. This prohibits libvirt from adding floppy disk for a PowerPC pseries VM. Signed-off-by: Kothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
2015-07-30 11:54:26 +00:00
/* PowerPC pseries based VMs do not support floppy device */
qemu: use qemuDomainMachineIsPSeries Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-13 14:24:45 +00:00
if (!qemuDomainMachineIsPSeries(machine, qemuCaps->arch))
Caps: Disable floppy disk for PowerPC VM PowerPC pseries based VMs do not support a floppy disk controller. This prohibits libvirt from adding floppy disk for a PowerPC pseries VM. Signed-off-by: Kothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
2015-07-30 11:54:26 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(disk->diskDevice, VIR_DOMAIN_DISK_DEVICE_FLOPPY);
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
qemu: report IDE bus in domain capabilities only if it's supported Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1441964 Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-13 13:29:16 +00:00
if (qemuDomainMachineHasBuiltinIDE(machine))
VIR_DOMAIN_CAPS_ENUM_SET(disk->bus, VIR_DOMAIN_DISK_BUS_IDE);
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(disk->bus,
VIR_DOMAIN_DISK_BUS_SCSI,
VIR_DOMAIN_DISK_BUS_VIRTIO,
/* VIR_DOMAIN_DISK_BUS_SD */);
Caps: Disable floppy disk for PowerPC VM PowerPC pseries based VMs do not support a floppy disk controller. This prohibits libvirt from adding floppy disk for a PowerPC pseries VM. Signed-off-by: Kothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
2015-07-30 11:54:26 +00:00
/* PowerPC pseries based VMs do not support floppy device */
qemu: use qemuDomainMachineIsPSeries Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-13 14:24:45 +00:00
if (!qemuDomainMachineIsPSeries(machine, qemuCaps->arch))
Caps: Disable floppy disk for PowerPC VM PowerPC pseries based VMs do not support a floppy disk controller. This prohibits libvirt from adding floppy disk for a PowerPC pseries VM. Signed-off-by: Kothapally Madhu Pavan <kmp@linux.vnet.ibm.com>
2015-07-30 11:54:26 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(disk->bus, VIR_DOMAIN_DISK_BUS_FDC);
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_USB_STORAGE))
VIR_DOMAIN_CAPS_ENUM_SET(disk->bus, VIR_DOMAIN_DISK_BUS_USB);
qemu_capabilities: report SATA bus in domain capabilities Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-03-06 16:16:07 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_ICH9_AHCI))
VIR_DOMAIN_CAPS_ENUM_SET(disk->bus, VIR_DOMAIN_DISK_BUS_SATA);
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
return 0;
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
}
domaincaps: Report graphics type enum Requires adding the plumbing for <device><graphics> Wire it up for qemu too
2016-05-08 15:57:20 +00:00
static int
virQEMUCapsFillDomainDeviceGraphicsCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsDeviceGraphicsPtr dev)
{
dev->supported = true;
qemu: deprecate QEMU_CAPS_SDL Implied by QEMU >= 1.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-03-29 10:51:55 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(dev->type, VIR_DOMAIN_GRAPHICS_TYPE_SDL);
domaincaps: Report graphics type enum Requires adding the plumbing for <device><graphics> Wire it up for qemu too
2016-05-08 15:57:20 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VNC))
VIR_DOMAIN_CAPS_ENUM_SET(dev->type, VIR_DOMAIN_GRAPHICS_TYPE_VNC);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SPICE))
VIR_DOMAIN_CAPS_ENUM_SET(dev->type, VIR_DOMAIN_GRAPHICS_TYPE_SPICE);
return 0;
}
domaincaps: Report video modelType Requires adding the plumbing for <device><video> The value is <enum name='modelType'> to match the associated domain XML of <video><model type='XXX'/> Wire it up for qemu too
2016-05-08 16:11:39 +00:00
static int
virQEMUCapsFillDomainDeviceVideoCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsDeviceVideoPtr dev)
{
dev->supported = true;
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VGA))
VIR_DOMAIN_CAPS_ENUM_SET(dev->modelType, VIR_DOMAIN_VIDEO_TYPE_VGA);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_CIRRUS_VGA))
VIR_DOMAIN_CAPS_ENUM_SET(dev->modelType, VIR_DOMAIN_VIDEO_TYPE_CIRRUS);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VMWARE_SVGA))
VIR_DOMAIN_CAPS_ENUM_SET(dev->modelType, VIR_DOMAIN_VIDEO_TYPE_VMVGA);
qemu_capabilities: join capabilities for qxl and qxl-vga devices This patch simplifies QEMU capabilities for QXL video device. QEMU exposes this device as *qxl-vga* and *qxl* and they are both the same device with the same set of parameters, the only difference is that *qxl-vga* includes VGA compatibility. Based on QEMU code they are tied together so it's safe to check only for presence of only one of them. This patch also removes an invalid test case "video-qxl-sec-nodevice" where there is only *qxl-vga* device and *qxl* device is not present. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-10-11 15:42:37 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_QXL))
domaincaps: Report video modelType Requires adding the plumbing for <device><video> The value is <enum name='modelType'> to match the associated domain XML of <video><model type='XXX'/> Wire it up for qemu too
2016-05-08 16:11:39 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(dev->modelType, VIR_DOMAIN_VIDEO_TYPE_QXL);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_GPU))
VIR_DOMAIN_CAPS_ENUM_SET(dev->modelType, VIR_DOMAIN_VIDEO_TYPE_VIRTIO);
return 0;
}
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
static int
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
virQEMUCapsFillDomainDeviceHostdevCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsDeviceHostdevPtr hostdev)
{
bool supportsPassthroughKVM = qemuHostdevHostSupportsPassthroughLegacy();
bool supportsPassthroughVFIO = qemuHostdevHostSupportsPassthroughVFIO();
conf: Get rid of virDomainCapsDevice The struct contains a single boolean field, 'supported': the meaning of this field is too generic to be limited to devices only, and in fact it's already being used for other things like loaders and OSs. Instead of trying to come up with a more generic name just get rid of the struct altogether.
2016-03-10 18:52:52 +00:00
hostdev->supported = true;
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
/* VIR_DOMAIN_HOSTDEV_MODE_CAPABILITIES is for containers only */
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->mode,
VIR_DOMAIN_HOSTDEV_MODE_SUBSYS);
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->startupPolicy,
VIR_DOMAIN_STARTUP_POLICY_DEFAULT,
VIR_DOMAIN_STARTUP_POLICY_MANDATORY,
VIR_DOMAIN_STARTUP_POLICY_REQUISITE,
VIR_DOMAIN_STARTUP_POLICY_OPTIONAL);
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->subsysType,
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB,
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI);
Deprecate QEMU_CAPS_DEVICE We support qemu version 0.12.0+, which has it.
2016-05-20 12:33:58 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_SCSI_GENERIC))
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->subsysType,
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI);
/* No virDomainHostdevCapsType for QEMU */
virDomainCapsEnumClear(&hostdev->capsType);
virDomainCapsEnumClear(&hostdev->pciBackend);
if (supportsPassthroughVFIO &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VFIO_PCI)) {
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->pciBackend,
VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT,
VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO);
}
Deprecate QEMU_CAPS_DEVICE We support qemu version 0.12.0+, which has it.
2016-05-20 12:33:58 +00:00
if (supportsPassthroughKVM) {
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->pciBackend,
VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT,
VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM);
}
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
return 0;
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
}
qemu: Add virQEMUCapsSupportsGICVersion() This utility function extracts some of the logic from virQEMUCapsFillDomainFeatureGICCaps() so that it can be used in a different context.
2016-05-16 11:23:01 +00:00
/**
* virQEMUCapsSupportsGICVersion:
* @qemuCaps: QEMU capabilities
* @virtType: domain type
* @version: GIC version
*
* Checks the QEMU binary with capabilities @qemuCaps supports a specific
qemu: capabilities: Tolerate missing @qemuCaps in virQEMUCapsSupportsGICVersion Report the given GIC version as unsupported if @qemuCapsi is NULL. This will be helpful to run post parse callbacks even if qemu is not currently installed.
2017-08-16 13:44:35 +00:00
* GIC version for a domain of type @virtType. If @qemuCaps is NULL, the GIC
* @version is considered unsupported.
qemu: Add virQEMUCapsSupportsGICVersion() This utility function extracts some of the logic from virQEMUCapsFillDomainFeatureGICCaps() so that it can be used in a different context.
2016-05-16 11:23:01 +00:00
*
* Returns: true if the binary supports the requested GIC version, false
* otherwise
*/
bool
virQEMUCapsSupportsGICVersion(virQEMUCapsPtr qemuCaps,
virDomainVirtType virtType,
virGICVersion version)
{
size_t i;
qemu: capabilities: Tolerate missing @qemuCaps in virQEMUCapsSupportsGICVersion Report the given GIC version as unsupported if @qemuCapsi is NULL. This will be helpful to run post parse callbacks even if qemu is not currently installed.
2017-08-16 13:44:35 +00:00
if (!qemuCaps)
return false;
qemu: Add virQEMUCapsSupportsGICVersion() This utility function extracts some of the logic from virQEMUCapsFillDomainFeatureGICCaps() so that it can be used in a different context.
2016-05-16 11:23:01 +00:00
for (i = 0; i < qemuCaps->ngicCapabilities; i++) {
virGICCapabilityPtr cap = &(qemuCaps->gicCapabilities[i]);
if (cap->version != version)
continue;
if (virtType == VIR_DOMAIN_VIRT_KVM &&
cap->implementation & VIR_GIC_IMPLEMENTATION_KERNEL)
return true;
if (virtType == VIR_DOMAIN_VIRT_QEMU &&
cap->implementation & VIR_GIC_IMPLEMENTATION_EMULATED)
return true;
}
return false;
}
qemu: Fill in GIC capabilities Take the GIC capabilities stored in a virQEMUCaps instance and update a virDomainCaps instance appropriately.
2016-03-09 18:18:24 +00:00
/**
* virQEMUCapsFillDomainFeatureGICCaps:
* @qemuCaps: QEMU capabilities
* @domCaps: domain capabilities
*
* Take the information about GIC capabilities that has been obtained
* using the 'query-gic-capabilities' QMP command and stored in @qemuCaps
* and convert it to a form suitable for @domCaps.
*
* @qemuCaps contains complete information about the GIC capabilities for
* the corresponding QEMU binary, stored as custom objects; @domCaps, on
* the other hand, should only contain information about the GIC versions
* available for the specific combination of architecture, machine type
* and virtualization type. Moreover, a common format is used to store
* information about enumerations in @domCaps, so further processing is
* required.
*
* Returns: 0 on success, <0 on failure
*/
static int
virQEMUCapsFillDomainFeatureGICCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsPtr domCaps)
{
virDomainCapsFeatureGICPtr gic = &domCaps->gic;
qemu: Add virQEMUCapsSupportsGICVersion() This utility function extracts some of the logic from virQEMUCapsFillDomainFeatureGICCaps() so that it can be used in a different context.
2016-05-16 11:23:01 +00:00
virGICVersion version;
qemu: Fill in GIC capabilities Take the GIC capabilities stored in a virQEMUCaps instance and update a virDomainCaps instance appropriately.
2016-03-09 18:18:24 +00:00
qemu: Rename qemuDomain*IsVirt() to qemuDomain*IsARMVirt() They're ARM specific. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-08-22 09:15:20 +00:00
if (!qemuDomainMachineIsARMVirt(domCaps->machine, domCaps->arch))
qemu: Fill in GIC capabilities Take the GIC capabilities stored in a virQEMUCaps instance and update a virDomainCaps instance appropriately.
2016-03-09 18:18:24 +00:00
return 0;
qemu: Add virQEMUCapsSupportsGICVersion() This utility function extracts some of the logic from virQEMUCapsFillDomainFeatureGICCaps() so that it can be used in a different context.
2016-05-16 11:23:01 +00:00
for (version = VIR_GIC_VERSION_LAST - 1;
version > VIR_GIC_VERSION_NONE;
version--) {
if (!virQEMUCapsSupportsGICVersion(qemuCaps,
domCaps->virttype,
version))
qemu: Fill in GIC capabilities Take the GIC capabilities stored in a virQEMUCaps instance and update a virDomainCaps instance appropriately.
2016-03-09 18:18:24 +00:00
continue;
gic->supported = true;
VIR_DOMAIN_CAPS_ENUM_SET(gic->version,
qemu: Add virQEMUCapsSupportsGICVersion() This utility function extracts some of the logic from virQEMUCapsFillDomainFeatureGICCaps() so that it can be used in a different context.
2016-05-16 11:23:01 +00:00
version);
qemu: Fill in GIC capabilities Take the GIC capabilities stored in a virQEMUCaps instance and update a virDomainCaps instance appropriately.
2016-03-09 18:18:24 +00:00
}
return 0;
}
conf: Expose SEV feature in domain capabilities Extend hypervisor capabilities to include sev feature. When available, hypervisor supports launching an encrypted VM on AMD platform. The sev feature tag provides additional details like Platform Diffie-Hellman (PDH) key and certificate chain which can be used by the guest owner to establish a cryptographic session with the SEV firmware to negotiate keys used for attestation or to provide secret during launch. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:52 +00:00
/**
* virQEMUCapsFillDomainFeatureSEVCaps:
* @qemuCaps: QEMU capabilities
* @domCaps: domain capabilities
*
* Take the information about SEV capabilities that has been obtained
* using the 'query-sev-capabilities' QMP command and stored in @qemuCaps
* and convert it to a form suitable for @domCaps.
*
* Returns: 0 on success, -1 on failure
*/
static int
virQEMUCapsFillDomainFeatureSEVCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsPtr domCaps)
{
virSEVCapability *cap = qemuCaps->sevCapabilities;
qemu: Define and use a auto cleanup function with virSEVCapability Keep with the recent effort of replacing as many explicit *Free functions with their automatic equivalents. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-15 15:02:06 +00:00
VIR_AUTOPTR(virSEVCapability) sev = NULL;
conf: Expose SEV feature in domain capabilities Extend hypervisor capabilities to include sev feature. When available, hypervisor supports launching an encrypted VM on AMD platform. The sev feature tag provides additional details like Platform Diffie-Hellman (PDH) key and certificate chain which can be used by the guest owner to establish a cryptographic session with the SEV firmware to negotiate keys used for attestation or to provide secret during launch. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:52 +00:00
if (!cap)
return 0;
if (VIR_ALLOC(sev) < 0)
return -1;
if (VIR_STRDUP(sev->pdh, cap->pdh) < 0)
qemu: Define and use a auto cleanup function with virSEVCapability Keep with the recent effort of replacing as many explicit *Free functions with their automatic equivalents. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-15 15:02:06 +00:00
return -1;
conf: Expose SEV feature in domain capabilities Extend hypervisor capabilities to include sev feature. When available, hypervisor supports launching an encrypted VM on AMD platform. The sev feature tag provides additional details like Platform Diffie-Hellman (PDH) key and certificate chain which can be used by the guest owner to establish a cryptographic session with the SEV firmware to negotiate keys used for attestation or to provide secret during launch. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:52 +00:00
if (VIR_STRDUP(sev->cert_chain, cap->cert_chain) < 0)
qemu: Define and use a auto cleanup function with virSEVCapability Keep with the recent effort of replacing as many explicit *Free functions with their automatic equivalents. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-15 15:02:06 +00:00
return -1;
conf: Expose SEV feature in domain capabilities Extend hypervisor capabilities to include sev feature. When available, hypervisor supports launching an encrypted VM on AMD platform. The sev feature tag provides additional details like Platform Diffie-Hellman (PDH) key and certificate chain which can be used by the guest owner to establish a cryptographic session with the SEV firmware to negotiate keys used for attestation or to provide secret during launch. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:52 +00:00
sev->cbitpos = cap->cbitpos;
sev->reduced_phys_bits = cap->reduced_phys_bits;
VIR_STEAL_PTR(domCaps->sev, sev);
qemu: Define and use a auto cleanup function with virSEVCapability Keep with the recent effort of replacing as many explicit *Free functions with their automatic equivalents. Signed-off-by: Erik Skultety <eskultet@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2018-08-15 15:02:06 +00:00
return 0;
conf: Expose SEV feature in domain capabilities Extend hypervisor capabilities to include sev feature. When available, hypervisor supports launching an encrypted VM on AMD platform. The sev feature tag provides additional details like Platform Diffie-Hellman (PDH) key and certificate chain which can be used by the guest owner to establish a cryptographic session with the SEV firmware to negotiate keys used for attestation or to provide secret during launch. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:52 +00:00
}
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
int
qemu: Fill in CPU domain capabilities Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-22 20:22:30 +00:00
virQEMUCapsFillDomainCaps(virCapsPtr caps,
virDomainCapsPtr domCaps,
domaincaps: Expose UEFI binary path, if it exists Check to see if the UEFI binary mentioned in qemu.conf actually exists, and if so expose it in domcapabilities like <loader ...> <value>/path/to/ovmf</value> </loader> We introduce some generic domcaps infrastructure for handling a dynamic list of string values, it may be of use for future bits. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 23:52:54 +00:00
virQEMUCapsPtr qemuCaps,
driver config: Introduce virFirmware object The virQEMUDriverConfig object contains lists of loader:nvram pairs to advertise firmwares supported by by the driver, and qemu_conf.c contains code to populate the lists, all of which is useful for other drivers too. To avoid code duplication, introduce a virFirmware object to encapsulate firmware details and switch the qemu driver to use it. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-17 22:45:27 +00:00
virFirmwarePtr *firmwares,
qemu: Remove redundant parameter in virQEMUCapsFillDomainCaps virttype is already included in domCaps, no need to pass it separately. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-27 13:12:34 +00:00
size_t nfirmwares)
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
{
domaincaps: Expose UEFI capability As of 542899168c38 we learned libvirt to use UEFI for domains. However, management applications may firstly query if libvirt supports it. And this is where virConnectGetDomainCapabilities() API comes handy. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-16 12:47:47 +00:00
virDomainCapsOSPtr os = &domCaps->os;
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
virDomainCapsDeviceDiskPtr disk = &domCaps->disk;
virDomainCapsDeviceHostdevPtr hostdev = &domCaps->hostdev;
domaincaps: Report graphics type enum Requires adding the plumbing for <device><graphics> Wire it up for qemu too
2016-05-08 15:57:20 +00:00
virDomainCapsDeviceGraphicsPtr graphics = &domCaps->graphics;
domaincaps: Report video modelType Requires adding the plumbing for <device><video> The value is <enum name='modelType'> to match the associated domain XML of <video><model type='XXX'/> Wire it up for qemu too
2016-05-08 16:11:39 +00:00
virDomainCapsDeviceVideoPtr video = &domCaps->video;
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
qemu: check the kvm host cpu max limits in virConnectGetDomainCapabilities The qemu limit and host limit both should be considered for the domain vcpu max limits. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
2016-06-24 15:04:13 +00:00
domCaps->maxvcpus = virQEMUCapsGetMachineMaxCpus(qemuCaps,
domCaps->machine);
qemu: Remove redundant parameter in virQEMUCapsFillDomainCaps virttype is already included in domCaps, no need to pass it separately. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-27 13:12:34 +00:00
if (domCaps->virttype == VIR_DOMAIN_VIRT_KVM) {
qemu: capabilities: Make virHostCPUGetKVMMaxVCPUs() errors fatal An error in virHostCPUGetKVMMaxVCPUs() means we've been unable to access /dev/kvm, or we're running on a platform that doesn't support KVM in the first place. If that's the case, we shouldn't ignore the error and report domcapabilities even though we know the user won't be able to start any KVM guest.
2016-06-27 11:53:43 +00:00
int hostmaxvcpus;
if ((hostmaxvcpus = virHostCPUGetKVMMaxVCPUs()) < 0)
return -1;
domCaps->maxvcpus = MIN(domCaps->maxvcpus, hostmaxvcpus);
qemu: check the kvm host cpu max limits in virConnectGetDomainCapabilities The qemu limit and host limit both should be considered for the domain vcpu max limits. Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
2016-06-24 15:04:13 +00:00
}
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
domain_capabilities: Report <vmcoreinfo> support Report <features><vmcoreinfo supported='yes'/> if the guest config accepts <features><vmcoreinfo state='on'/> Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2018-04-17 17:54:28 +00:00
domCaps->vmcoreinfo = virQEMUCapsGet(qemuCaps,
QEMU_CAPS_DEVICE_VMCOREINFO);
domcaps: Add 'genid' to domain capabilities Report domaincaps <features><genid supported='yes'/> if the guest config accepts <genid/> or <genid>$GUID</genid>. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-04-27 12:16:40 +00:00
domCaps->genid = virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VMGENID);
driver config: Introduce virFirmware object The virQEMUDriverConfig object contains lists of loader:nvram pairs to advertise firmwares supported by by the driver, and qemu_conf.c contains code to populate the lists, all of which is useful for other drivers too. To avoid code duplication, introduce a virFirmware object to encapsulate firmware details and switch the qemu driver to use it. Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2016-05-17 22:45:27 +00:00
if (virQEMUCapsFillDomainOSCaps(os, firmwares, nfirmwares) < 0 ||
qemu: Fill in CPU domain capabilities Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-22 20:22:30 +00:00
virQEMUCapsFillDomainCPUCaps(caps, qemuCaps, domCaps) < 0 ||
qemu: Add I/O thread support info into domain capabilities Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-10-19 12:19:38 +00:00
virQEMUCapsFillDomainIOThreadCaps(qemuCaps, domCaps) < 0 ||
domaincaps: Report graphics type enum Requires adding the plumbing for <device><graphics> Wire it up for qemu too
2016-05-08 15:57:20 +00:00
virQEMUCapsFillDomainDeviceDiskCaps(qemuCaps,
domCaps->machine, disk) < 0 ||
virQEMUCapsFillDomainDeviceGraphicsCaps(qemuCaps, graphics) < 0 ||
domaincaps: Report video modelType Requires adding the plumbing for <device><video> The value is <enum name='modelType'> to match the associated domain XML of <video><model type='XXX'/> Wire it up for qemu too
2016-05-08 16:11:39 +00:00
virQEMUCapsFillDomainDeviceVideoCaps(qemuCaps, video) < 0 ||
qemu: Fill in GIC capabilities Take the GIC capabilities stored in a virQEMUCaps instance and update a virDomainCaps instance appropriately.
2016-03-09 18:18:24 +00:00
virQEMUCapsFillDomainDeviceHostdevCaps(qemuCaps, hostdev) < 0 ||
conf: Expose SEV feature in domain capabilities Extend hypervisor capabilities to include sev feature. When available, hypervisor supports launching an encrypted VM on AMD platform. The sev feature tag provides additional details like Platform Diffie-Hellman (PDH) key and certificate chain which can be used by the guest owner to establish a cryptographic session with the SEV firmware to negotiate keys used for attestation or to provide secret during launch. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:52 +00:00
virQEMUCapsFillDomainFeatureGICCaps(qemuCaps, domCaps) < 0 ||
virQEMUCapsFillDomainFeatureSEVCaps(qemuCaps, domCaps) < 0)
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
return -1;
conf: Expose SEV feature in domain capabilities Extend hypervisor capabilities to include sev feature. When available, hypervisor supports launching an encrypted VM on AMD platform. The sev feature tag provides additional details like Platform Diffie-Hellman (PDH) key and certificate chain which can be used by the guest owner to establish a cryptographic session with the SEV firmware to negotiate keys used for attestation or to provide secret during launch. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-08 14:40:52 +00:00
qemu_capabilities: Change virQEMUCapsFillDomainCaps signature Up till now the virQEMUCapsFillDomainCaps() was type of void as there was no way for it to fail. This is, however, going to change in the next commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-17 09:33:35 +00:00
return 0;
qemu: Implement virConnectGetDomainCapabilities So far only information on disks and host devices are exposed in the capabilities XML. Well, at least something. Even a new test is introduced. The qemu capabilities are stolen from already existing qemucapabilities test. There's one tricky point though. Functions that checks host's KVM and VFIO capabilities, are impossible to mock currently. So in the test, we are setting the capabilities by hand. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-25 16:39:29 +00:00
}
qemu: capabilities: force update if the microcode version does not match A microcode update can cause the CPUID bits to change; an example from the past was the update that disabled TSX on several Haswell and Broadwell machines. Therefore, place microcode version in the virQEMUCaps struct and XML, and rebuild the cache if the versions do not match. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-12-12 15:23:41 +00:00
void
virQEMUCapsSetMicrocodeVersion(virQEMUCapsPtr qemuCaps,
unsigned int microcodeVersion)
{
qemuCaps->microcodeVersion = microcodeVersion;
}
tests: qemuxml2argv: Make tests based on DO_TEST_CAPS_LATEST stable To avoid problems with test cases specifying an alias machine type which would change once capabilities for a newer version are added strip all alias machine types for the DO_TEST_CAPS_LATEST based tests. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-06-04 13:30:49 +00:00
/**
* virQEMUCapsStripMachineAliases:
* @qemuCaps: capabilities object to process
*
* Remove all aliases so that the tests depending on the latest capabilities
* file can be stable when new files are added.
*/
void
virQEMUCapsStripMachineAliases(virQEMUCapsPtr qemuCaps)
{
size_t i;
for (i = 0; i < qemuCaps->nmachineTypes; i++)
VIR_FREE(qemuCaps->machineTypes[i].alias);
}
Reference in New Issue Copy Permalink