External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-10-31 18:33:11 +00:00
Code Issues Packages Projects Releases Wiki Activity
6e9c4811be
libvirt/src/qemu/qemu_capabilities.c

6452 lines
201 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
*/
#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"
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
#include "virarch.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"
Enforce a standard header file guard symbol name Require that all headers are guarded by a symbol named LIBVIRT_$FILENAME where $FILENAME is the uppercased filename, with all characters outside a-z changed into '_'. Note we do not use a leading __ because that is technically a namespace reserved for the toolchain. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-13 14:53:50 +00:00
#define LIBVIRT_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"
qemu_process: Move process code from qemu_capabilities QEMU process code in qemu_capabilities.c is moved to qemu_process.c in order to make the code usable outside the original capabilities use cases. The moved code activates and manages QEMU processes without establishing a guest domain. This patch is a straight cut/paste move between files. Signed-off-by: Chris Venteicher <cventeic@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-01-13 00:50:00 +00:00
#include "qemu_process.h"
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
#include "qemu_firmware.h"
virsh: include virutil.h where used Include virutil.h in all files that use it, instead of relying on it being pulled in somehow. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-02-16 21:59:28 +00:00
#include "virutil.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>
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
*/
Always put _LAST enums on second line of VIR_ENUM_IMPL Standardize on putting the _LAST enum value on the second line of VIR_ENUM_IMPL invocations. Later patches that add string labels to VIR_ENUM_IMPL will push most of these to the second line anyways, so this saves some noise. Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-16 18:20:32 +00:00
VIR_ENUM_IMPL(virQEMUCaps,
QEMU_CAPS_LAST, /* virQEMUCaps grouping marker */
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 */
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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
"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
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 */
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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
"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
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 */
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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
"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
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 */
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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
"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
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 */
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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
"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
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 */
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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
"rtc",
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
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 */
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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
"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
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 */
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",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 40 */
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
"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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 45 */
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
"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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 50 */
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-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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 55 */
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-spicevmc",
"virtio-tx-alg",
"device-qxl-vga",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 60 */
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",
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
"cache-directsync",
Add various USB devices QEMU_CAPS
2011-09-02 12:56:50 +00:00
"piix3-usb-uhci",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 65 */
Add various USB devices QEMU_CAPS
2011-09-02 12:56:50 +00:00
"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
"vt82c686b-usb-uhci",
Add various USB devices QEMU_CAPS
2011-09-02 12:56:50 +00:00
"pci-ohci",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 70 */
Add various USB devices QEMU_CAPS
2011-09-02 12:56:50 +00:00
"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",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 75 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 80 */
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",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 85 */
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",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 90 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 95 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 100 */
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
"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",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 105 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 110 */
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",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 115 */
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-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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 120 */
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
"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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 125 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 130 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 135 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 140 */
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
"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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 145 */
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: 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
"vnc-share-policy",
qemu: Add support for DEVICE_DELETED event
2013-07-11 15:07:26 +00:00
"device-del-event",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 150 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 155 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 160 */
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
"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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 165 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 170 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 175 */
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",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 180 */
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
"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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 185 */
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
"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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 190 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 195 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 200 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 205 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 210 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 215 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 220 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 225 */
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",
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 230 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 235 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 240 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 245 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 250 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 255 */
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: 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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 260 */
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.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: 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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 265 */
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
"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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 270 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 275 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 280 */
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",
"virtio-mouse-ccw",
"virtio-tablet-ccw",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 285 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 290 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 295 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 300 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 305 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 310 */
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
"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",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 315 */
qemu: add vfio-ap capability Introduce vfio-ap capability. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Chris Venteicher <cventeic@redhat.com>
2018-10-18 14:54:06 +00:00
"vfio-ap",
qemu: Introduce zPCI capability Let's introduce zPCI capability. Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Stefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-11-08 11:00:20 +00:00
"zpci",
qemu: add memory-backend-memfd capability check Check availability of "-object memory-backend-memfd". Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-15 11:55:51 +00:00
"memory-backend-memfd",
qemu: check memory-backend-memfd.hugetlb capability QEMU 3.1 should only expose the property if the host is actually capable of creating hugetable-backed memfd. However, it may fail at runtime depending on requested "hugetlbsize". Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-15 11:55:52 +00:00
"memory-backend-memfd.hugetlb",
qemu: Detect whether iothread polling is supported Add a capability check for IOThread polling (all were added at the same time, so only one check is necessary). Based on code originally posted by Pavel Hrdina <phrdina@redhat.com> with the only changes to include the more recent QEMU releases. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-10-05 19:59:49 +00:00
"iothread.poll-max-ns",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 320 */
qemu: Introduce QEMU_CAPS_MACHINE_PSERIES_CAP_NESTED_HV Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-11-20 12:56:38 +00:00
"machine.pseries.cap-nested-hv",
qemu: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_ALIGN capability This capability tracks if memory-backend-file has the align attribute or not. Signed-off-by: Luyao Zhong <luyao.zhong@intel.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-12-20 09:14:43 +00:00
"egl-headless.rendernode",
"memory-backend-file.align",
qemu: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_PMEM capability This capability tracks if memory-backend-file has the pmem attribute or not. Signed-off-by: Luyao Zhong <luyao.zhong@intel.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-12-20 09:14:44 +00:00
"memory-backend-file.pmem",
qemu: Introduce QEMU_CAPS_DEVICE_NVDIMM_UNARMED capability This capability tracks if nvdimm has the unarmed attribute or not for the nvdimm readonly xml attribute. Signed-off-by: Luyao Zhong <luyao.zhong@intel.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-12-20 09:14:45 +00:00
"nvdimm.unarmed",
Delete QEMU_CAPS_KQEMU and QEMU_CAPS_ENABLE_KQEMU Support for kqemu was dropped in libvirt by commit 8e91a400c and even back then we never set these capabilities when doing QMP probing. Since no QEMU we aim to support has these, drop them completely. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-04-03 07:13:21 +00:00
/* 325 */
qemu: caps: Introduce capability for 'device_id' property of 'scsi-disk' The property allows to control the guest-visible content of the vendor specific designator of the 'Device Identification' page of a SCSI device's VPD (vital product data). QEMU was leaking the id string of -drive as the value if the 'serial' of the disk was not specified. Switching to -blockdev would impose an ABI change. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-01-28 08:30:41 +00:00
"scsi-disk.device_id",
qemu: capabilities: Add virtio/vhost {non-}transitional Add a single QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL that will be set if any of the following qemu devices are found: virtio-blk-pci-transitional virtio-blk-pci-non-transitional virtio-net-pci-transitional virtio-net-pci-non-transitional vhost-scsi-pci-transitional vhost-scsi-pci-non-transitional virtio-rng-pci-transitional virtio-rng-pci-non-transitional virtio-9p-pci-transitional virtio-9p-pci-non-transitional virtio-balloon-pci-transitional virtio-balloon-pci-non-transitional vhost-vsock-pci-transitional vhost-vsock-pci-non-transitional virtio-input-host-pci-transitional virtio-input-host-pci-non-transitional virtio-scsi-pci-transitional virtio-scsi-pci-non-transitional virtio-serial-pci-transitional virtio-serial-pci-non-transitional Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-01-22 18:17:06 +00:00
"virtio-pci-non-transitional",
qemu_capabilities: Introduce QEMU_CAPS_OVERCOMMIT Added in QEMU commit of v3.0.0-rc0~48^2~9 (then fixed by v3.1.0-rc0~119^2~37) QEMU is replacing '-realtime mlock' with '-overcommit mem-lock'. Add a capability to tell if we're dealing new new enough qemu to use the replacement. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 08:16:06 +00:00
"overcommit",
qemu_capabilities: Add QEMU_CAPS_QUERY_CURRENT_MACHINE QEMU commit 46ea94ca9cf ("qmp: query-current-machine with wakeup-suspend-support") added a new QMP command called 'query-current-machine' that retrieves guest parameters that can vary in the same machine model (e.g. ACPI support for x86 VMs depends on the '--no-acpi' option). Currently, this API has a single flag, 'wakeup-suspend-support', that indicates whether the guest has the capability of waking up from suspended state. Introduce a libvirt capability that reflects whether qemu has the monitor command. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2019-04-24 21:16:27 +00:00
"query-current-machine",
qemu: Introduce QEMU_CAPS_MACHINE_VIRT_IOMMU This capability can be used to figure out whether the QEMU binary at hand supports the machine type property we need in order to enable SMMUv3 IOMMU support. Unfortunately we can't avoid probing the RISC-V binaries along with the ARM ones, since both architectures have their own 'virt' machine type. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-05-17 07:15:27 +00:00
"machine.virt.iommu",
backup: Add two new qemu capabilities Add two capabilities for testing features required for the upcoming virDomainBackupBegin: use block-dirty-bitmap-merge as the generic witness of bitmap support needed for checkpoints (since all of the bitmap management functionalities were finalized in the same qemu 4.0 release), and the bitmap parameter to nbd-server-add for pull-mode backup support. Even though both capabilities are likely to be present or absent together (that is, it is unlikely to encounter a qemu that backports only one of the two), it still makes sense to keep two capabilities as the two uses are orthogonal (full backups don't require checkpoints, push mode backups don't require NBD bitmap support, and checkpoints can be used for more than just incremental backups). Existing code is not affected by the new capabilities. Signed-off-by: Eric Blake <eblake@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2019-06-06 02:25:05 +00:00
/* 330 */
"bitmap-merge",
"nbd-bitmap",
qemu: Probe for max-x86_64-cpu type We will use it to check whether QEMU supports a specific CPU property. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-10 14:46:10 +00:00
"x86-max-cpu",
qemu: Probe for "unavailable-features" CPU property It is similar to "filtered-features" property, which reports CPUID bits corresponding to disabled features, but more general. The "unavailable-features" property supports both CPUID and MSR features by listing their names. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-10 14:49:22 +00:00
"cpu-unavailable-features",
qemu_command: Use canonical names of CPU features When building QEMU command line, we should use the preferred spelling of each CPU feature without relying on compatibility aliases (which may be removed at some point). The "unavailable-features" CPU property is used as a witness for the correct names of the features in our translation table. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-07 13:00:28 +00:00
"canonical-cpu-features",
qemu: Add bochs-display capability Check whether qemu supports the bochs-display device and set a capability. Update tests. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2019-07-12 20:12:15 +00:00
/* 335 */
"bochs-display",
qemu: Check for drop-cache capability QEMU 4.0.0 and newer automatically drops caches at the end of migration. Let's check for this capability so that we can allow migration when disk cache is turned on. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Acked-By: Peter Krempa <pkrempa@redhat.com>
2019-08-13 13:17:36 +00:00
"migration-file-drop-cache",
qemu: add dbus-vmstate capability This object is being proposed to qemu upstream "Add dbus-vmstate object". It handles data migration of external processes. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-08-08 14:54:57 +00:00
"dbus-vmstate",
qemu: add vhost-user-gpu capabilities checks Those new devices are available since QEMU 4.1. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-23 10:44:29 +00:00
"vhost-user-gpu",
"vhost-user-vga",
qemu: caps: Add capability for incremental backup support Add a new all-covering capability which will be used to interlock incremental backup support until all bits are ready. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2019-09-26 11:01:30 +00:00
/* 340 */
"incremental-backup",
qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_BASELINE This capability enables baselining of CPU models via QMP. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Message-Id: <1568924706-2311-9-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:24:59 +00:00
"query-cpu-model-baseline",
qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_COMPARISON This capability enables comparison of CPU models via QMP. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Message-Id: <1568924706-2311-13-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:25:03 +00:00
"query-cpu-model-comparison",
qemu: add ramfb capability Add a qemu capbility to see if the standalone ramfb device is available. Reviewed-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
2019-09-13 21:20:28 +00:00
"ramfb",
qemu: Add capability for the ccf-assist pSeries feature Linux kernel 5.1 added a new PPC KVM capability named KVM_PPC_CPU_CHAR_BCCTR_FLUSH_ASSIST, which is exposed to the QEMU guest since QEMU commit 8ff43ee404d under a new sPAPR capability called SPAPR_CAP_CCF_ASSIST. This cap indicates whether the processor supports hardware acceleration for the count cache flush workaround, which is a software workaround that flushes the count cache on context switch. If the processor has this hardware acceleration, the software flush can be shortened, resulting in performance gain. This hardware acceleration is defaulted to 'off' in QEMU. The reason is that earlier versions of the Power 9 processor didn't support it (it is available on Power 9 DD2.3 and newer), and defaulting this option to 'on' would break migration compatibility between the Power 9 processor class. However, the user running a P9 DD2.3+ hypervisor might want to create guests with ccf-assist=on, accepting the downside of only being able to migrate them only between other P9 DD2.3+ hosts running upstream kernel 5.1+, to get a performance boost. This patch adds this new capability to Libvirt, with the name of QEMU_CAPS_MACHINE_PSERIES_CAP_CCF_ASSIST. Reviewed-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-10-08 20:06:23 +00:00
"machine.pseries.cap-ccf-assist",
qemu: Introduce QEMU_CAPS_ARM_MAX_CPU Mirrors the existing QEMU_CAPS_X86_MAX_CPU. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-07-08 11:21:00 +00:00
/* 345 */
"arm-max-cpu",
qemu: caps: Add capability for dynamic 'auto-read-only' support for files Initial implementation of 'auto-read-only' didn't reopen the backing files when needed. For '-blockdev' to work we need to be able to tel qemu to open a file read-only and change it during blockjobs as we label backing chains with a sVirt label which does not allow writing. The dynamic auto-read-only supports this as it reopens files when writing is demanded. Add a capability to detect that the posix file based backends support the dynamic part. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-08 15:10:37 +00:00
"blockdev-file-dynamic-auto-read-only",
qemu: capabilities: Add detection of the 'savevm' fix for -blockdev The 'savevm' HMP command didn't work properly with blockdev as it tried to do snapshot of everything including the protocol nodes accessing files which are not snapshottable. Qemu fixed this bug so now we need to detect it to allow enabling blockdev. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-17 15:10:08 +00:00
"savevm-monitor-nodes",
qemu_capabilities: Introduce QEMU_CAPS_DRIVE_NVME This capability tracks if qemu is capable of: -drive file.driver=nvme The feature was added in QEMU's commit of v2.12.0-rc0~104^2~2. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-06-05 14:11:03 +00:00
"drive-nvme",
qemu: add support for specifying CPU "dies" topology parameter QEMU since 4.1.0 supports the "dies" parameter for -smp Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-16 15:28:09 +00:00
"smp-dies",
qemu: Refuse to use "ps2" on machines that do not have this bus The "ps2" bus is only available on certain machines like x86. On machines like s390x, we should refuse to add a device to this bus instead of silently ignoring it. Looking at the QEMU sources, PS/2 is only available if the QEMU binary has the "i8042" device, so let's check for that and only allow "ps2" devices if this QEMU device is available, or if we're on x86 anyway (so we don't have to fake the QEMU_CAPS_DEVICE_I8042 capability in all the tests that use <input ... bus='ps2'/> in their xml data). Reported-by: Sebastian Mitterle <smitterl@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1763191 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-15 12:23:56 +00:00
/* 350 */
"i8042",
qemu_capabilities: Introduce QEMU_CAPS_OBJECT_RNG_BUILTIN It is used to check if qemu is capable of rng-builtin object. This object is added since qemu-4.2.0-rc0, commit 6c4e9d48. Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-09 08:00:05 +00:00
"rng-builtin",
qemu: add capabilities flag for failover feature Presence of the virtio-net-pci option called "failover" indicates support in a qemu binary of a simplistic bonding of a virtio-net device with another PCI device. This feature allows migration of guests that have a network device assigned to a guest with VFIO, by creating a network bond device in the guest consisting of the VFIO-assigned device and a virtio-net-pci device, then temporarily (and automatically) unplugging the VFIO net device prior to migration (and hotplugging an equivalent device on the migration destination). (The feature is called "failover" because the bond device uses the vfio-pci netdev for normal guest networking, but "fails over" to the virtio-net-pci netdev once the vfio-pci device is unplugged for migration.) Full functioning of the feature also requires support in the virtio-net driver in the guest OS (since that is where the bond device resides), but if the "failover" commandline option is present for the virtio-net-pci device in qemu, at least the qemu part of the feature is available, and libvirt can add the proper options to both the virtio-net-pci and vfio-pci device commandlines to indicate qemu should attempt doing the failover during migration. This patch just adds the qemu capabilities flag "virtio-net.failover". Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-08 19:22:34 +00:00
"virtio-net.failover",
qemu: Extend QEMU capabilities with 'tpm-spapr' Extend the QEMU capabilties with tpm-spapr support. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-02-05 18:35:47 +00:00
"tpm-spapr",
qemu: Add the QEMU_CAPS_CPU_KVM_NO_ADJVTIME capability We will use this capability to detect whether the QEMU binary supports the kvm-no-adjvtime CPU feature. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-01-31 13:28:57 +00:00
"cpu.kvm-no-adjvtime",
qemu: add QEMU_CAPS_DEVICE_VHOST_USER_FS Introduced by QEMU commit 98fc1ada4cf70af0f1df1a2d7183cf786fc7da05 virtio: add vhost-user-fs base device Released in QEMU v4.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Andrea Bolognani <abologna@redhat.com>
2019-02-06 12:29:00 +00:00
/* 355 */
"vhost-user-fs",
qemu: capabilities: Add capability for the 'flat' argument of 'query-named-block-nodes' Detect the presence of the flag and make it available internally as QEMU_CAPS_QMP_QUERY_NAMED_BLOCK_NODES_FLAT. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-01-21 14:13:47 +00:00
"query-named-block-nodes.flat",
qemu: capabilities: Introduce QEMU_CAPS_BLOCKDEV_SNAPSHOT_ALLOW_WRITE_ONLY The capability is based on qemu's support of using blockdev-snapshot to install backing chain also for images which are in use by a block-copy job. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2020-03-05 13:28:50 +00:00
"blockdev-snapshot.allow-write-only-overlay",
qemu: capabilities: Add QEMU_CAPS_BLOCKDEV_REOPEN This capability will be asserted once qemu stabilizes 'blockdev-reopen'. For now we just add the capability so that we can introduce some code that will use the reopening call. This will show our willingness to adopt use of reopen and help qemu developers stabilize it. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2020-02-27 11:23:29 +00:00
"blockdev-reopen",
qemu: add QEMU_CAPS_STORAGE_WERROR Detect the werror property on SCSI and virtio disks. But clear it if the QEMU supports usb-storage device without it also supporting this option for usb-storage. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-04-01 08:22:30 +00:00
"storage.werror",
qemu: capabilities: add QEMU_CAPS_FSDEV_MULTIDEVS The QEMU 9pfs 'multidevs' option exists since QEMU 4.2. Probe QEMU's command line set though to check whether this option is really available, and if yes enable this new QEMU_CAPS_FSDEV_MULTIDEVS capability on libvirt side. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-03-30 18:04:47 +00:00
/* 360 */
"fsdev.multidevs",
qemu: capabilities: add 'packed' capability Add the capability for QEMU's packed virtqueues for virtio that supposedly have better cache utilization and performance compared to the default split queues. Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-04-06 13:13:24 +00:00
"virtio.packed",
qemu: new capabilities flag pcie-root-port.hotplug This caps flag is set when the qemu binary supports the option "hotplug" for pcie-root-port, ioh3420 (Intel pcie-root-port) and xio3130-downstream (Intel pcie-downstream-port). If it's available, it's possible to disable hotplugging/unplugging devices on a particular port by adding ",hotplug=off" to the qemu device commandline. This option first appears in qemu-5.0.0. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-02-27 20:22:59 +00:00
"pcie-root-port.hotplug",
qemu_capabilities: Introduce QEMU_CAPS_AIO_IO_URING Add io_uring value to capability replies. The capability QEMU_CAPS_AIO_IO_URING will be used for io_uring aio mode, introduced from QEMU 5.0, linux 5.1. Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-04-21 12:19:34 +00:00
"aio.io_uring",
qemu: Add capability for CFPC pSeries feature CFPC (Cache Flush on Privilege Change) is one of the capabilities added to QEMU to mitigate Spectre vulnerabilities in Power chips. It was implemented in QEMU 2.12 by commit 6898aed77f46. This capability is still used today due to differences in how the host setup (hardware and firmware/kernel) can handle this mitigation. Its default value also varies with the pseries machine version of the time. There's also certain OSes, like AIX, that might not support the default value of the pseries machine the guest uses. Exposing this in the Libvirt XML as a feature will allow users to tune CFPC values in a cleaner way, instead of hacking parameters in <qemu:commandline> elements. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 12:14:26 +00:00
"machine.pseries.cap-cfpc",
qemu: Add capability for SBBC pSeries feature SBBC (Speculation Barrier Bounds Checking) is another capability related to Spectre mitigation efforts in Power processors. It was implemented in QEMU 2.12 by commit 09114fd81799. This patch introduces it as QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC to be implemented in the next patch. Like the case with the now implemented CFPC, exposing this feature in the XML allows for a cleaner way for users to tune the SBBC accordingly, given that not all hypervisor and guest setups supports this Spectre mitigation. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 12:14:28 +00:00
/* 365 */
"machine.pseries.cap-sbbc",
qemu: Add capability for IBS pSeries feature IBS (Indirect Branch Speculation) is the last capability added in QEMU 2.12 related to Spectre mitigation for Power. It was added in commit 4be8d4e7d935. This patch introduces it as QEMU_CAPS_MACHINE_PSERIES_CAP_IBS. Like CFPC and SBBC, users might want to tune in IBS based on their HW and guest OS requirements, and it's better to do it so in a proper Libvirt feature than to put QEMU arguments in the middle of the domain XML. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 12:14:30 +00:00
"machine.pseries.cap-ibs",
qemu: Introduce QEMU_CAPS_TCG Since QEMU 2.10 it is possible to disable TCG when building QEMU. Introduce a capability that reflects this. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-28 09:04:14 +00:00
"tcg",
qemu: capabilities: Introduce QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED Historically the 'scsi' passthrough feature of virtio-blk-pci was enabled by default. Libvirt was disabling it due to security implications outlined in libvirt commit v0.9.9-4-g177db08775 if it was not explicitly requested. In qemu commit v2.4.0-1566-ged65fd1a27 the default value was changed to disabled in preparation for virtio-1. Starting from QEMU-5.0 the 'scsi' property was also deprecated. There replacement for the functionality is to use 'virtio-scsi' for the purpose. This isn't a direct replacement though. Add capability named QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED which allows us to stop formatting the 'scsi=' property if it's disabled by default and not requested so that we don't use deprecated features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 20:01:51 +00:00
"virtio-blk-pci.scsi.default.disabled",
qemu: pvscsi: Add capability This capability flags support for `-device pvscsi`, which provides the VMware paravirtual SCSI controller. Signed-off-by: Chris Jester-Young <cky@cky.nz> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-05-13 01:55:45 +00:00
"pvscsi",
qemu: Probe for .migratable property of a CPU Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-02 18:15:53 +00:00
/* 370 */
"cpu.migratable",
qemu: Probe for migrtability support in CPU expansion Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-02 23:05:36 +00:00
"query-cpu-model-expansion.migratable",
qemu: Introduce fw_cfg capability This capability tracks whether QEMU supports -fw_cfg command line option, more specifically whether it allows specifying filename. There are some releases of QEMU which support -fw_cfg but not filename. If this is ever a problem we can refine the capability later on. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 14:57:56 +00:00
"fw_cfg",
qemu: Probe for a few params supported by migrate-set-parameters These parameters were originally set via dedicated commands which are now deprecated. We want to use migrate-set-parameters instead if possible. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-06-10 13:09:00 +00:00
"migration-param.bandwidth",
"migration-param.downtime",
/* 375 */
"migration-param.xbzrle-cache-size",
qemu: format address wdith on intel-iommu command line Format the address width attribute. Depending on the version of QEMU it is named 'aw-bits' or 'x-aw-bits'. Signed-off-by: Menno Lageman <menno.lageman@oracle.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-04 07:42:43 +00:00
"intel-iommu.aw-bits",
qemu: Extend QEMU capabilities with 'spapr-tpm-proxy' Expose the TPM Proxy support for PPC64 guests by creating a new cap called QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY. This device is part of the machinery the guest need to orchestrate with the PPC64 Ultravisor the transition to the Secure VM (SVM) mode. Inside QEMU, this device will be used with the H_TPM_COMM hypercall to connect with the TPM Resource Manager, enabling the guest to open and close TPM sessions with the host TPM. Tested-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-10 18:11:44 +00:00
"spapr-tpm-proxy",
qemu: Introduce QEMU_CAPS_NUMA_HMAT capability This capability tracks whether QEMU is capable of defining HMAT ACPI table for the guest. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-27 09:00:07 +00:00
"numa.hmat",
qemu: capabilities: add missing comma Signed-off-by: Ján Tomko <jtomko@redhat.com> Fixes: bab9257a649386a908069ba890a23f2a5ff5b131
2020-08-03 14:20:28 +00:00
"blockdev-hostdev-scsi",
qemu_capabilities: Add QEMU_CAPS_USB_HOST_HOSTDEVICE This capability tracks whether "usb-host" device has "hostdevice" attribute. This attribute allows us to specify full path to the USB device ("/dev/bus/usb/$bus/$dev") but more importantly, since QEMU uses qemu_open() for this attribute it allows us to pass pre-opened FD and have QEMU not bother with opening the file at all. The attribute was added in v5.1.0-rc0~71^2~1 QEMU commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-09-09 09:13:52 +00:00
/* 380 */
"usb-host.hostdevice",
QEMU: declare qemu capabilities for the Virtio Free page reporting feature This patch will introduce the free-page-reporting feature capabilities that are in qemu 5.1 Signed-off-by: Nico Pache <npache@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-12 23:35:37 +00:00
"virtio-balloon.free-page-reporting",
qemu: capabilities: Add QEMU_CAPS_BLOCK_EXPORT_ADD The 'block-export-add' QMP command is a replacement for 'nbd-server-add' and will allow greater flexibility. Add a capability so that we can switch to it. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-14 09:42:58 +00:00
"block-export-add",
qemu: add vhost-vdpa capability Recent versions of qemu added the -netdev vhost-vdpa device. This capability allows libvirt to know whether this is supported. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
2020-10-14 17:08:26 +00:00
"netdev.vhost-vdpa",
qemu: capabilities: add QEMU_CAPS_FSDEV_CREATEMODE The QEMU 9pfs 'fmode' and 'dmode' options have existed since QEMU 2.10. Probe QEMU's command line set to check whether these options are available, and if yes, enable this new QEMU_CAPS_FSDEV_CREATEMODE capability on libvirt side. Signed-off-by: Brian Turek <brian.turek@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-10-08 14:32:23 +00:00
"fsdev.createmode",
qemu: add capabilities for the three ESP family SCSI controllers Probing for the NCR53C90 controller is a little unusual. The qom-list-types QMP command returns a list of all types known to the QEMU binary. It does not distinguish devices which are user creatable from those which are built-in. Any QEMU target that supports PCI will have the DC390 / AM53C974 devices because they are PCI based. Due to code dependencies in QEMU though, existence of these two devices will also pull in the NCR53C90 device (called just 'esp' in QEMU). The NCR53C90 is not user-creatable and can only be used when built-in to the machine type. This is only the case on sparc machines, and certain mips64 and m68k machines. IOW, we don't rely on qom-list-types as a guide for existence of NCR53C90, as it shouldn't really exist in most QEMU binaries. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-18 16:37:54 +00:00
/* 385 */
"ncr53c90",
"dc390",
"am53c974",
qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_PMEM_PCI This commit introduces a new capability that reflects virtio-pmem-pci device support in qemu: QEMU_CAPS_DEVICE_VIRTIO_PMEM_PCI, /* -device virtio-pmem-pci */ The virtio-pmem-pci device was introduced in QEMU 4.1. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2021-01-15 12:31:51 +00:00
"virtio-pmem-pci",
qemu: add QEMU_CAPS_VHOST_USER_FS_BOOTINDEX Introduced by QEMU commit: commit 6da32fe5efdd71c9d254a436ce972194ff631285 Author: Laszlo Ersek <lersek@redhat.com> AuthorDate: 2021-01-12 14:16:03 +0100 Commit: Michael S. Tsirkin <mst@redhat.com> CommitDate: 2021-01-13 09:06:37 -0500 vhost-user-fs: add the "bootindex" property Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-01-04 15:03:57 +00:00
"vhost-user-fs.bootindex",
qemu_capabilities: introduce vhost-user-blk capability Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-02-02 12:37:02 +00:00
/* 390 */
"vhost-user-blk",
qemu: probe for "-cpu max" support This is a special CPU model similar to "-cpu host", so won't use our normal CPU model detection logic. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-05 18:21:14 +00:00
"cpu-max",
qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID This capability tracks whether memory-backend-file has "x-use-canonical-path-for-ramblock-id" attribute. Introduced into QEMU by commit fa0cb34d2210cc749b9a70db99bb41c56ad20831. As of QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9 the property is considered stable by qemu despite the 'x-' prefix to preserve compatibility with released qemu versions. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-01-11 17:15:57 +00:00
"memory-backend-file.x-use-canonical-path-for-ramblock-id",
qemu: probe for -vnc supporting use of QemuOpts syntax This was introduced in QEMU 2.2.0, and is visible by -vnc appearing in the "query-command-line-options" data. Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-16 11:45:46 +00:00
"vnc-opts",
qemu: capabilities: Introduce QEMU_CAPS_MIGRATION_PARAM_BLOCK_BITMAP_MAPPING The capability represents qemu's ability to setup mappings for migrating block dirty bitmaps and is based on presence of the 'transform' property of the 'block-bitmap-mapping' property of 'migrate-set-parameters' QMP command. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2020-08-07 09:29:18 +00:00
"migration-param.block-bitmap-mapping",
qemu: probe for -vnc power-control option support Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-16 13:34:26 +00:00
/* 395 */
"vnc-power-control",
qemu: probe for -vnc audiodev property The -audiodev arg is a new way to configure audio devices in QEMU to replace the QEMU_AUDIO_DRV env variable. This arg is not visible in the "query-command-line-options" output since it is entirely QAPI driven, not QemuOpts. It also isn't in "query-qmp-schema" though since there's no QMP command that uses the Audiodev type yet. So probe for the existance of this feature by looking for the -vnc "audiodev" property. This won't let us determine which precise audio backends QEMU has been built with, but for now that's no worse than with env variables today. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-23 16:16:28 +00:00
"audiodev",
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: Use typedef for virQEMUCapsMachineType Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-30 00:04:06 +00:00
typedef struct _virQEMUCapsMachineType virQEMUCapsMachineType;
typedef virQEMUCapsMachineType *virQEMUCapsMachineTypePtr;
struct _virQEMUCapsMachineType {
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
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: Probe for default CPU types QEMU 4.2.0 will report default CPU types used by each machine type and we will want to start using it. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-07-18 17:21:55 +00:00
char *defaultCPU;
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
bool numaMemSupported;
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
char *defaultRAMid;
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
bool deprecated;
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
src: fix word spell typos Signed-off-by: Fangge Jin <fjin@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-07-09 04:42:21 +00:00
* re-computed from other fields and external data sources every time we
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
* 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
};
qemu: Introduce virQEMUCapsAccel structure This is container for capabilities data that depend on the accelerator. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:29:52 +00:00
typedef struct _virQEMUCapsAccel virQEMUCapsAccel;
typedef virQEMUCapsAccel *virQEMUCapsAccelPtr;
struct _virQEMUCapsAccel {
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
size_t nmachineTypes;
virQEMUCapsMachineTypePtr machineTypes;
qemu: Introduce virQEMUCapsAccel structure This is container for capabilities data that depend on the accelerator. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:29:52 +00:00
virQEMUCapsHostCPUData hostCPU;
qemuMonitorCPUDefsPtr cpuModels;
};
qemu_capabilities: Rework domain caps cache Since v5.6.0-48-g270583ed98 we try to cache domain capabilities, i.e. store filled virDomainCaps in a hash table in virQEMUCaps for future use. However, there's a race condition in the way it's implemented. We use virQEMUCapsGetDomainCapsCache() to obtain the pointer to the hash table, then we search the hash table for cached data and if none is found the domcaps is constructed and put into the table. Problem is that this is all done without any locking, so if there are two threads trying to do the same, one will succeed and the other will fail inserting the data into the table. Also, the API looks a bit fishy - obtaining pointer to the hash table is dangerous. The solution is to use a mutex that guards the whole operation with the hash table. Then, the API can be changes to return virDomainCapsPtr directly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1791790 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-01-24 09:43:29 +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
qemu: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
bool kvmSupportsNesting;
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
bool kvmSupportsSecureGuest;
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
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;
qemu: Check for changes in qemu modules directory Add a configuration option for specifying location of the qemu modules directory, defaulting to /usr/lib64/qemu. Then use this location to check for changes in the directory, indicating that a qemu module has changed and capabilities need to be reprobed. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-20 21:52:17 +00:00
time_t modDirMtime;
qemu: add explicit flag to skip qemu caps invalidation Currently if the binary path is NULL in the qemu capabilities object, cache invalidation is skipped. A future patch will ensure that the binary path is always non-NULL, so a way to explicitly skip invalidation is required. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 11:56:38 +00:00
bool invalidation;
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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
char *hostCPUSignature;
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 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: Introduce virQEMUCapsAccel structure This is container for capabilities data that depend on the accelerator. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:29:52 +00:00
/* Capabilities which may differ depending on the accelerator. */
virQEMUCapsAccel kvm;
virQEMUCapsAccel tcg;
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;
qemu: Prefer qemu-system-* binaries We already prefer them in capabilities, and domcapabilities should be consistent with that. This commit is best viewed with 'git show -w'. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-14 12:36:15 +00:00
const char *binaryFilter;
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
};
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;
}
Require a semicolon for VIR_ONCE_GLOBAL_INIT calls Missing semicolon at the end of macros can confuse some analyzers (like cppcheck <filename>). VIR_ONCE_GLOBAL_INIT is almost exclusively called without an ending semicolon, but let's standardize on using one like the other macros. Add a dummy struct definition at the end of the macro, so the compiler will require callers to add a semicolon. Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-01-20 17:23:29 +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
qemu_capabilities: Expose qemu <-> libvirt arch translators In some cases, the string representing architecture is different in qemu and libvirt. That is the reason why we have virQEMUCapsArchFromString() and virQEMUCapsArchToString(). So far, we did not need them outside of qemu_capabilities code, but this will change shortly. Expose them then. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-26 09:42:38 +00:00
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);
}
qemu_capabilities: Expose qemu <-> libvirt arch translators In some cases, the string representing architecture is different in qemu and libvirt. That is the reason why we have virQEMUCapsArchFromString() and virQEMUCapsArchToString(). So far, we did not need them outside of qemu_capabilities code, but this will change shortly. Expose them then. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-26 09:42:38 +00:00
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";
Add armv6l Support as guest Support for armv6l qemu guests has been added. Tested with arm1176 CPU on x86. Signed-off-by: Stefan Schallenberg <infos@nafets.de> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-11-28 21:45:14 +00:00
else if (arch == VIR_ARCH_ARMV6L || arch == VIR_ARCH_ARMV7L)
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 "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)
{
qemu: Move comments to virQEMUCapsGuestIsNative() The function performing the checks, rather than its callers, should contain comments explaining the rationale behind said checks. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 11:32:29 +00:00
/* host & guest arches match */
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 (host == guest)
return true;
qemu: Move comments to virQEMUCapsGuestIsNative() The function performing the checks, rather than its callers, should contain comments explaining the rationale behind said checks. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 11:32:29 +00:00
/* hostarch is x86_64 and guest arch is i686 (needs -cpu qemu32) */
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 (host == VIR_ARCH_X86_64 && guest == VIR_ARCH_I686)
return true;
qemu: Move comments to virQEMUCapsGuestIsNative() The function performing the checks, rather than its callers, should contain comments explaining the rationale behind said checks. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 11:32:29 +00:00
/* hostarch is aarch64 and guest arch is armv7l (needs -cpu aarch64=off) */
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 (host == VIR_ARCH_AARCH64 && guest == VIR_ARCH_ARMV7L)
return true;
qemu: Move comments to virQEMUCapsGuestIsNative() The function performing the checks, rather than its callers, should contain comments explaining the rationale behind said checks. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 11:32:29 +00:00
/* hostarch and guestarch are both ppc64 */
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 (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: Introduce and use virQEMUCapsGetAccel The function can be used to get the pointer to all data which depend on the accelerator. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:46:28 +00:00
static virQEMUCapsAccelPtr
virQEMUCapsGetAccel(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
if (type == VIR_DOMAIN_VIRT_KVM)
return &qemuCaps->kvm;
return &qemuCaps->tcg;
}
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
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsSetDefaultMachine(virQEMUCapsAccelPtr caps,
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
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: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsMachineType tmp = caps->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
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
memmove(caps->machineTypes + 1,
caps->machineTypes,
sizeof(caps->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
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
caps->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: Use g_strdup_printf() instead of virAsprintf() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-10-22 13:26:14 +00:00
binary = g_strdup_printf(format, archstr);
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;
qemu: Move armv7l-on-aarch64 special case When running an armv7l guest on an aarch64 hosts, the qemu-system-aarch64 binary should be our first choice instead of qemu-system-arm since the former can take advantage of KVM acceleration. Move the special case to virQEMUCapsFindBinaryForArch() so that it's handled along with all other cases rather than on its own later on. Doing so will also make further refactoring easier. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 14:27:42 +00:00
/* armv7l guests can only take advantage of KVM on aarch64 hosts by
* using the qemu-system-aarch64 binary, so look for that one first
* to avoid using qemu-system-arm (and thus TCG) instead */
if (hostarch == VIR_ARCH_AARCH64 && guestarch == VIR_ARCH_ARMV7L) {
archstr = virQEMUCapsArchToString(hostarch);
if ((ret = virQEMUCapsFindBinary("qemu-system-%s", archstr)) != NULL)
qemu: remove unneeded labels Remove unneeded, easy to remove goto labels (cleanup|error|done|...). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-01-06 21:57:40 +00:00
return ret;
qemu: Move armv7l-on-aarch64 special case When running an armv7l guest on an aarch64 hosts, the qemu-system-aarch64 binary should be our first choice instead of qemu-system-arm since the former can take advantage of KVM acceleration. Move the special case to virQEMUCapsFindBinaryForArch() so that it's handled along with all other cases rather than on its own later on. Doing so will also make further refactoring easier. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 14:27:42 +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
/* First attempt: try the guest architecture as it is */
archstr = virQEMUCapsArchToString(guestarch);
if ((ret = virQEMUCapsFindBinary("qemu-system-%s", archstr)) != NULL)
qemu: remove unneeded labels Remove unneeded, easy to remove goto labels (cleanup|error|done|...). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-01-06 21:57:40 +00:00
return ret;
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
/* 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)
qemu: remove unneeded labels Remove unneeded, easy to remove goto labels (cleanup|error|done|...). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-01-06 21:57:40 +00:00
return ret;
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
return ret;
}
conf: drop virCapsPtr param from basic post parse callback The QEMU impl of the callback can directly use the QEMU capabilities cache to resolve the emulator binary name, allowing virCapsPtr to be dropped. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 16:53:53 +00:00
char *
virQEMUCapsGetDefaultEmulator(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
{
char *binary = NULL;
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: Simplify QEMU binary search Now that we have reduced the number of sensible options down to either the native QEMU binary or RHEL's qemu-kvm, we can make virQEMUCapsInitGuest() a bit simpler. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 15:45:40 +00:00
/* RHEL doesn't follow the usual naming for QEMU binaries and ships
* a single binary named qemu-kvm outside of $PATH instead */
qemu: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
if (virQEMUCapsGuestIsNative(hostarch, guestarch) && !binary)
binary = g_strdup("/usr/libexec/qemu-kvm");
qemu: Simplify QEMU binary search Now that we have reduced the number of sensible options down to either the native QEMU binary or RHEL's qemu-kvm, we can make virQEMUCapsInitGuest() a bit simpler. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 15:45:40 +00:00
conf: drop virCapsPtr param from basic post parse callback The QEMU impl of the callback can directly use the QEMU capabilities cache to resolve the emulator binary name, allowing virCapsPtr to be dropped. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 16:53:53 +00:00
return binary;
}
static int
virQEMUCapsInitGuest(virCapsPtr caps,
virFileCachePtr cache,
virArch hostarch,
virArch guestarch)
{
char *binary = NULL;
virQEMUCapsPtr qemuCaps = NULL;
int ret = -1;
binary = virQEMUCapsGetDefaultEmulator(hostarch, guestarch);
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: Rename qemubinCaps => qemuCaps The latter is used throughout libvirt, so use it here as well for consistency. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 16:24:35 +00:00
if (!(qemuCaps = 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: 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,
qemu: Rename qemubinCaps => qemuCaps The latter is used throughout libvirt, so use it here as well for consistency. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 16:24:35 +00:00
binary, qemuCaps,
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
guestarch);
VIR_FREE(binary);
qemu: Rename qemubinCaps => qemuCaps The latter is used throughout libvirt, so use it here as well for consistency. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 16:24:35 +00:00
virObjectUnref(qemuCaps);
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;
}
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
static int
virQEMUCapsGetMachineTypesCaps(virQEMUCapsPtr qemuCaps,
size_t *nmachines,
virCapsGuestMachinePtr **machines)
{
size_t i;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsAccelPtr accel;
/* Guest capabilities do not report TCG vs. KVM caps separately. We just
* take the set of machine types we probed first. */
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
accel = &qemuCaps->kvm;
else
accel = &qemuCaps->tcg;
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
*machines = NULL;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
*nmachines = accel->nmachineTypes;
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
if (*nmachines)
*machines = g_new0(virCapsGuestMachinePtr, accel->nmachineTypes);
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
for (i = 0; i < accel->nmachineTypes; i++) {
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
virCapsGuestMachinePtr mach;
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
mach = g_new0(virCapsGuestMachine, 1);
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
(*machines)[i] = mach;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
if (accel->machineTypes[i].alias) {
mach->name = g_strdup(accel->machineTypes[i].alias);
mach->canonical = g_strdup(accel->machineTypes[i].name);
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
} else {
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
mach->name = g_strdup(accel->machineTypes[i].name);
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
}
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
mach->maxCpus = accel->machineTypes[i].maxCpus;
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
mach->deprecated = accel->machineTypes[i].deprecated;
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +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;
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
mach = g_new0(virCapsGuestMachine, 1);
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
if (VIR_INSERT_ELEMENT_COPY(*machines, i, *nmachines, mach) < 0) {
VIR_FREE(mach);
goto error;
}
mach->name = g_strdup(machine->canonical);
mach->maxCpus = machine->maxCpus;
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
mach->deprecated = machine->deprecated;
qemu: Make virQEMUCapsGetMachineTypesCaps static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:08:57 +00:00
i++;
}
i++;
}
return 0;
error:
virCapabilitiesFreeMachines(*machines, *nmachines);
*nmachines = 0;
*machines = NULL;
return -1;
}
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
int
virQEMUCapsInitGuestFromBinary(virCapsPtr caps,
const char *binary,
qemu: Rename qemubinCaps => qemuCaps The latter is used throughout libvirt, so use it here as well for consistency. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 16:24:35 +00:00
virQEMUCapsPtr qemuCaps,
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
virArch guestarch)
{
virCapsGuestPtr guest;
virCapsGuestMachinePtr *machines = NULL;
size_t nmachines = 0;
int ret = -1;
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: Rename qemubinCaps => qemuCaps The latter is used throughout libvirt, so use it here as well for consistency. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 16:24:35 +00:00
if (virQEMUCapsGetMachineTypesCaps(qemuCaps, &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' */
conf: capabilities: Refactor API for setting guest capability features Remove the need to pass around strings and switch to the enum values instead. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-12 12:57:23 +00:00
virCapabilitiesAddGuestFeature(guest, VIR_CAPS_GUEST_FEATURE_TYPE_CPUSELECTION);
virCapabilitiesAddGuestFeature(guest, VIR_CAPS_GUEST_FEATURE_TYPE_DEVICEBOOT);
virCapabilitiesAddGuestFeatureWithToggle(guest, VIR_CAPS_GUEST_FEATURE_TYPE_DISKSNAPSHOT,
true, false);
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
qemu: Fix capabilities probing with TCG Only probe QEMU binary with accel=tcg if TCG is not disabled. Similarly, only add a VIR_DOMAIN_VIRT_QEMU guest if TCG is available. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-22 21:50:42 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_TCG)) {
if (virCapabilitiesAddGuestDomain(guest,
VIR_DOMAIN_VIRT_QEMU,
NULL,
NULL,
0,
NULL) == 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: Rename qemubinCaps => qemuCaps The latter is used throughout libvirt, so use it here as well for consistency. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 16:24:35 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
qemu: Remove unnecessary variables Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 15:06:48 +00:00
if (virCapabilitiesAddGuestDomain(guest,
VIR_DOMAIN_VIRT_KVM,
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;
Remove xenner support Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-22 16:29:01 +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
}
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
conf: capabilities: Refactor API for setting guest capability features Remove the need to pass around strings and switch to the enum values instead. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-12 12:57:23 +00:00
if ((ARCH_IS_X86(guestarch) || guestarch == VIR_ARCH_AARCH64))
virCapabilitiesAddGuestFeatureWithToggle(guest, VIR_CAPS_GUEST_FEATURE_TYPE_ACPI,
true, true);
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
conf: capabilities: Refactor API for setting guest capability features Remove the need to pass around strings and switch to the enum values instead. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-12 12:57:23 +00:00
if (ARCH_IS_X86(guestarch))
virCapabilitiesAddGuestFeatureWithToggle(guest, VIR_CAPS_GUEST_FEATURE_TYPE_APIC,
true, false);
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
conf: capabilities: Refactor API for setting guest capability features Remove the need to pass around strings and switch to the enum values instead. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-12 12:57:23 +00:00
if (guestarch == VIR_ARCH_I686) {
virCapabilitiesAddGuestFeature(guest, VIR_CAPS_GUEST_FEATURE_TYPE_PAE);
virCapabilitiesAddGuestFeature(guest, VIR_CAPS_GUEST_FEATURE_TYPE_NONPAE);
}
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: Make virQEMUCapsProbeHostCPUForEmulator more generic The function is renamed as virQEMUCapsProbeHostCPU and it does not get the list of allowed CPU models from qemuCaps anymore. This is responsibility is moved to the caller. The result is just a very thin wrapper around virCPUGetHost mostly required mocking in tests. The generic function is used in place of a direct call to virCPUGetHost in virQEMUCapsInitHostCPUModel to make sure tests don't accidentally probe host CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2019-06-03 11:13:38 +00:00
virQEMUCapsProbeHostCPU(virArch hostArch,
virDomainCapsCPUModelsPtr models)
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: Make virQEMUCapsProbeHostCPUForEmulator more generic The function is renamed as virQEMUCapsProbeHostCPU and it does not get the list of allowed CPU models from qemuCaps anymore. This is responsibility is moved to the caller. The result is just a very thin wrapper around virCPUGetHost mostly required mocking in tests. The generic function is used in place of a direct call to virCPUGetHost in virQEMUCapsInitHostCPUModel to make sure tests don't accidentally probe host CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2019-06-03 11:13:38 +00:00
return virCPUGetHost(hostArch, VIR_CPU_TYPE_GUEST, NULL, models);
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
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");
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[] = {
{ "dump-guest-memory", QEMU_CAPS_DUMP_GUEST_MEMORY },
{ "query-spice", QEMU_CAPS_SPICE },
{ "query-vnc", QEMU_CAPS_VNC },
{ "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_capabilities: Add QEMU_CAPS_QUERY_CURRENT_MACHINE QEMU commit 46ea94ca9cf ("qmp: query-current-machine with wakeup-suspend-support") added a new QMP command called 'query-current-machine' that retrieves guest parameters that can vary in the same machine model (e.g. ACPI support for x86 VMs depends on the '--no-acpi' option). Currently, this API has a single flag, 'wakeup-suspend-support', that indicates whether the guest has the capability of waking up from suspended state. Introduce a libvirt capability that reflects whether qemu has the monitor command. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2019-04-24 21:16:27 +00:00
{ "query-current-machine", QEMU_CAPS_QUERY_CURRENT_MACHINE },
backup: Add two new qemu capabilities Add two capabilities for testing features required for the upcoming virDomainBackupBegin: use block-dirty-bitmap-merge as the generic witness of bitmap support needed for checkpoints (since all of the bitmap management functionalities were finalized in the same qemu 4.0 release), and the bitmap parameter to nbd-server-add for pull-mode backup support. Even though both capabilities are likely to be present or absent together (that is, it is unlikely to encounter a qemu that backports only one of the two), it still makes sense to keep two capabilities as the two uses are orthogonal (full backups don't require checkpoints, push mode backups don't require NBD bitmap support, and checkpoints can be used for more than just incremental backups). Existing code is not affected by the new capabilities. Signed-off-by: Eric Blake <eblake@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2019-06-06 02:25:05 +00:00
{ "block-dirty-bitmap-merge", QEMU_CAPS_BITMAP_MERGE },
qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_BASELINE This capability enables baselining of CPU models via QMP. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Message-Id: <1568924706-2311-9-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:24:59 +00:00
{ "query-cpu-model-baseline", QEMU_CAPS_QUERY_CPU_MODEL_BASELINE },
qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_COMPARISON This capability enables comparison of CPU models via QMP. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Message-Id: <1568924706-2311-13-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:25:03 +00:00
{ "query-cpu-model-comparison", QEMU_CAPS_QUERY_CPU_MODEL_COMPARISON },
qemu: capabilities: Re-enable detection of QEMU_CAPS_BLOCK_EXPORT_ADD Now that qemu stabilized it's interface and we've switched to the new design we can re-enable use of 'block-export-add' This reverts commit b87cfc957f57c1d9f7e5bf828ee4b23972085991 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2020-10-26 12:09:17 +00:00
{ "block-export-add", QEMU_CAPS_BLOCK_EXPORT_ADD },
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: caps: Probe events from 'query-qmp-schema' rather than 'query-events' QEMU plans to deprecate 'query-events' as it's non-extensible. Events are also described by 'query-qmp-schema' so we can use that one instead. This patch adds detection of events to virQEMUCapsProbeQMPSchemaCapabilities using the same structure declaring them for the old approach (virQEMUCapsEvents). This is possible as the name is the same in the QMP schema and our detector supports that trivially. For any complex queries virQEMUCapsQMPSchemaQueries can be used in the future. For now we still call 'query-events' and discard the result so that it's obvious that the tests pass. This will be cleaned up later. https://bugzilla.redhat.com/show_bug.cgi?id=1673320 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-02-07 11:50:27 +00:00
/* Use virQEMUCapsQMPSchemaQueries for querying parameters of events */
qemu: Make probing for events declarative
2013-06-19 07:24:54 +00:00
struct virQEMUCapsStringFlags virQEMUCapsEvents[] = {
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: 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 },
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: 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 },
qemu: add vfio-ap capability Introduce vfio-ap capability. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Chris Venteicher <cventeic@redhat.com>
2018-10-18 14:54:06 +00:00
{ "vfio-ap", QEMU_CAPS_DEVICE_VFIO_AP },
qemu: Introduce zPCI capability Let's introduce zPCI capability. Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Stefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-11-08 11:00:20 +00:00
{ "zpci", QEMU_CAPS_DEVICE_ZPCI },
qemu: add memory-backend-memfd capability check Check availability of "-object memory-backend-memfd". Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-15 11:55:51 +00:00
{ "memory-backend-memfd", QEMU_CAPS_OBJECT_MEMORY_MEMFD },
qemu: capabilities: Add virtio/vhost {non-}transitional Add a single QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL that will be set if any of the following qemu devices are found: virtio-blk-pci-transitional virtio-blk-pci-non-transitional virtio-net-pci-transitional virtio-net-pci-non-transitional vhost-scsi-pci-transitional vhost-scsi-pci-non-transitional virtio-rng-pci-transitional virtio-rng-pci-non-transitional virtio-9p-pci-transitional virtio-9p-pci-non-transitional virtio-balloon-pci-transitional virtio-balloon-pci-non-transitional vhost-vsock-pci-transitional vhost-vsock-pci-non-transitional virtio-input-host-pci-transitional virtio-input-host-pci-non-transitional virtio-scsi-pci-transitional virtio-scsi-pci-non-transitional virtio-serial-pci-transitional virtio-serial-pci-non-transitional Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-01-22 18:17:06 +00:00
{ "virtio-blk-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-blk-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-net-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-net-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "vhost-scsi-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "vhost-scsi-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-rng-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-rng-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-9p-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-9p-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-balloon-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-balloon-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "vhost-vsock-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "vhost-vsock-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-input-host-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-input-host-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-scsi-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-scsi-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-serial-pci-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
{ "virtio-serial-pci-non-transitional", QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL },
qemu: Probe for max-x86_64-cpu type We will use it to check whether QEMU supports a specific CPU property. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-10 14:46:10 +00:00
{ "max-x86_64-cpu", QEMU_CAPS_X86_MAX_CPU },
qemu: Add bochs-display capability Check whether qemu supports the bochs-display device and set a capability. Update tests. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2019-07-12 20:12:15 +00:00
{ "bochs-display", QEMU_CAPS_DEVICE_BOCHS_DISPLAY },
Revert "qemu_capabilities: Temporarily disable dbus-vmstate capability" This reverts commit 929e0bd267fe735924d445df6bb5e6d02330f3c3. I've mistakenly pushed wrong branch. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2019-09-19 09:27:12 +00:00
{ "dbus-vmstate", QEMU_CAPS_DBUS_VMSTATE },
qemu: add vhost-user-gpu capabilities checks Those new devices are available since QEMU 4.1. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-23 10:44:29 +00:00
{ "vhost-user-gpu", QEMU_CAPS_DEVICE_VHOST_USER_GPU },
{ "vhost-user-vga", QEMU_CAPS_DEVICE_VHOST_USER_VGA },
qemu: add ramfb capability Add a qemu capbility to see if the standalone ramfb device is available. Reviewed-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
2019-09-13 21:20:28 +00:00
{ "ramfb", QEMU_CAPS_DEVICE_RAMFB },
qemu: Introduce QEMU_CAPS_ARM_MAX_CPU Mirrors the existing QEMU_CAPS_X86_MAX_CPU. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-07-08 11:21:00 +00:00
{ "max-arm-cpu", QEMU_CAPS_ARM_MAX_CPU },
qemu: Refuse to use "ps2" on machines that do not have this bus The "ps2" bus is only available on certain machines like x86. On machines like s390x, we should refuse to add a device to this bus instead of silently ignoring it. Looking at the QEMU sources, PS/2 is only available if the QEMU binary has the "i8042" device, so let's check for that and only allow "ps2" devices if this QEMU device is available, or if we're on x86 anyway (so we don't have to fake the QEMU_CAPS_DEVICE_I8042 capability in all the tests that use <input ... bus='ps2'/> in their xml data). Reported-by: Sebastian Mitterle <smitterl@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1763191 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-15 12:23:56 +00:00
{ "i8042", QEMU_CAPS_DEVICE_I8042 },
qemu_capabilities: Introduce QEMU_CAPS_OBJECT_RNG_BUILTIN It is used to check if qemu is capable of rng-builtin object. This object is added since qemu-4.2.0-rc0, commit 6c4e9d48. Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-09 08:00:05 +00:00
{ "rng-builtin", QEMU_CAPS_OBJECT_RNG_BUILTIN },
qemu: Extend QEMU capabilities with 'tpm-spapr' Extend the QEMU capabilties with tpm-spapr support. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-02-05 18:35:47 +00:00
{ "tpm-spapr", QEMU_CAPS_DEVICE_TPM_SPAPR },
qemu: add QEMU_CAPS_DEVICE_VHOST_USER_FS Introduced by QEMU commit 98fc1ada4cf70af0f1df1a2d7183cf786fc7da05 virtio: add vhost-user-fs base device Released in QEMU v4.2.0. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Andrea Bolognani <abologna@redhat.com>
2019-02-06 12:29:00 +00:00
{ "vhost-user-fs-device", QEMU_CAPS_DEVICE_VHOST_USER_FS },
qemu: Introduce QEMU_CAPS_TCG Since QEMU 2.10 it is possible to disable TCG when building QEMU. Introduce a capability that reflects this. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-28 09:04:14 +00:00
{ "tcg-accel", QEMU_CAPS_TCG },
qemu: pvscsi: Add capability This capability flags support for `-device pvscsi`, which provides the VMware paravirtual SCSI controller. Signed-off-by: Chris Jester-Young <cky@cky.nz> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-05-13 01:55:45 +00:00
{ "pvscsi", QEMU_CAPS_SCSI_PVSCSI },
qemu: Extend QEMU capabilities with 'spapr-tpm-proxy' Expose the TPM Proxy support for PPC64 guests by creating a new cap called QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY. This device is part of the machinery the guest need to orchestrate with the PPC64 Ultravisor the transition to the Secure VM (SVM) mode. Inside QEMU, this device will be used with the H_TPM_COMM hypercall to connect with the TPM Resource Manager, enabling the guest to open and close TPM sessions with the host TPM. Tested-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-10 18:11:44 +00:00
{ "spapr-tpm-proxy", QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY },
qemu: add capabilities for the three ESP family SCSI controllers Probing for the NCR53C90 controller is a little unusual. The qom-list-types QMP command returns a list of all types known to the QEMU binary. It does not distinguish devices which are user creatable from those which are built-in. Any QEMU target that supports PCI will have the DC390 / AM53C974 devices because they are PCI based. Due to code dependencies in QEMU though, existence of these two devices will also pull in the NCR53C90 device (called just 'esp' in QEMU). The NCR53C90 is not user-creatable and can only be used when built-in to the machine type. This is only the case on sparc machines, and certain mips64 and m68k machines. IOW, we don't rely on qom-list-types as a guide for existence of NCR53C90, as it shouldn't really exist in most QEMU binaries. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-18 16:37:54 +00:00
/*
* We don't probe 'esp' directly, because it is often reported
* as present for all QEMU binaries, due to it being enabled
* for built as a dependancy of dc390/am53c974 PCI SCSI
* controllers.
*
* The base 'esp' device is only used as a built-in device
* and is not user-creatable. So we turn this cap on later
* based on arch.
*
* { "esp", QEMU_CAPS_SCSI_NCR53C90 },
*/
{ "dc390", QEMU_CAPS_SCSI_DC390 },
{ "am53c974", QEMU_CAPS_SCSI_AM53C974 },
qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_PMEM_PCI This commit introduces a new capability that reflects virtio-pmem-pci device support in qemu: QEMU_CAPS_DEVICE_VIRTIO_PMEM_PCI, /* -device virtio-pmem-pci */ The virtio-pmem-pci device was introduced in QEMU 4.1. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2021-01-15 12:31:51 +00:00
{ "virtio-pmem-pci", QEMU_CAPS_DEVICE_VIRTIO_PMEM_PCI },
qemu_capabilities: introduce vhost-user-blk capability Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-02-02 12:37:02 +00:00
{ "vhost-user-blk", QEMU_CAPS_DEVICE_VHOST_USER_BLK },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
struct virQEMUCapsDevicePropsFlags {
const char *value;
int flag;
int (*cb)(virJSONValuePtr props, virQEMUCapsPtr caps);
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVirtioBalloon[] = {
{ "deflate-on-oom", QEMU_CAPS_VIRTIO_BALLOON_AUTODEFLATE, NULL },
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY, NULL },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM, NULL },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS, NULL },
{ "packed", QEMU_CAPS_VIRTIO_PACKED_QUEUES, NULL },
QEMU: declare qemu capabilities for the Virtio Free page reporting feature This patch will introduce the free-page-reporting feature capabilities that are in qemu 5.1 Signed-off-by: Nico Pache <npache@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-10-12 23:35:37 +00:00
{ "free-page-reporting", QEMU_CAPS_VIRTIO_BALLOON_FREE_PAGE_REPORTING, NULL },
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_VIRTIO_BLK_SCSI_DEFAULT_DISABLED Historically the 'scsi' passthrough feature of virtio-blk-pci was enabled by default. Libvirt was disabling it due to security implications outlined in libvirt commit v0.9.9-4-g177db08775 if it was not explicitly requested. In qemu commit v2.4.0-1566-ged65fd1a27 the default value was changed to disabled in preparation for virtio-1. Starting from QEMU-5.0 the 'scsi' property was also deprecated. There replacement for the functionality is to use 'virtio-scsi' for the purpose. This isn't a direct replacement though. Add capability named QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED which allows us to stop formatting the 'scsi=' property if it's disabled by default and not requested so that we don't use deprecated features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 20:01:51 +00:00
static int
virQEMUCapsDevicePropsVirtioBlkSCSIDefault(virJSONValuePtr props,
virQEMUCapsPtr qemuCaps)
{
bool def = false;
if (virJSONValueObjectGetBoolean(props, "default-value", &def) < 0)
return 0;
if (def == false)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED);
return 0;
}
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVirtioBlk[] = {
{ "ioeventfd", QEMU_CAPS_VIRTIO_IOEVENTFD, NULL },
{ "event_idx", QEMU_CAPS_VIRTIO_BLK_EVENT_IDX, NULL },
qemu: capabilities: Introduce QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED Historically the 'scsi' passthrough feature of virtio-blk-pci was enabled by default. Libvirt was disabling it due to security implications outlined in libvirt commit v0.9.9-4-g177db08775 if it was not explicitly requested. In qemu commit v2.4.0-1566-ged65fd1a27 the default value was changed to disabled in preparation for virtio-1. Starting from QEMU-5.0 the 'scsi' property was also deprecated. There replacement for the functionality is to use 'virtio-scsi' for the purpose. This isn't a direct replacement though. Add capability named QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED which allows us to stop formatting the 'scsi=' property if it's disabled by default and not requested so that we don't use deprecated features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 20:01:51 +00:00
{ "scsi", QEMU_CAPS_VIRTIO_BLK_SCSI, virQEMUCapsDevicePropsVirtioBlkSCSIDefault },
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
{ "logical_block_size", QEMU_CAPS_BLOCKIO, NULL },
{ "num-queues", QEMU_CAPS_VIRTIO_BLK_NUM_QUEUES, NULL },
{ "share-rw", QEMU_CAPS_DISK_SHARE_RW, NULL },
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY, NULL },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM, NULL },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS, NULL },
{ "write-cache", QEMU_CAPS_DISK_WRITE_CACHE, NULL },
{ "werror", QEMU_CAPS_STORAGE_WERROR, NULL },
{ "packed", QEMU_CAPS_VIRTIO_PACKED_QUEUES, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVirtioNet[] = {
{ "tx", QEMU_CAPS_VIRTIO_TX_ALG, NULL },
{ "event_idx", QEMU_CAPS_VIRTIO_NET_EVENT_IDX, NULL },
{ "rx_queue_size", QEMU_CAPS_VIRTIO_NET_RX_QUEUE_SIZE, NULL },
{ "tx_queue_size", QEMU_CAPS_VIRTIO_NET_TX_QUEUE_SIZE, NULL },
{ "host_mtu", QEMU_CAPS_VIRTIO_NET_HOST_MTU, NULL },
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY, NULL },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM, NULL },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS, NULL },
{ "failover", QEMU_CAPS_VIRTIO_NET_FAILOVER, NULL },
{ "packed", QEMU_CAPS_VIRTIO_PACKED_QUEUES, NULL },
qemu: new capabilities flag pcie-root-port.hotplug This caps flag is set when the qemu binary supports the option "hotplug" for pcie-root-port, ioh3420 (Intel pcie-root-port) and xio3130-downstream (Intel pcie-downstream-port). If it's available, it's possible to disable hotplugging/unplugging devices on a particular port by adding ",hotplug=off" to the qemu device commandline. This option first appears in qemu-5.0.0. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-02-27 20:22:59 +00:00
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsPCIeRootPort[] = {
{ "hotplug", QEMU_CAPS_PCIE_ROOT_PORT_HOTPLUG, NULL },
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_capabilities: Add QEMU_CAPS_USB_HOST_HOSTDEVICE This capability tracks whether "usb-host" device has "hostdevice" attribute. This attribute allows us to specify full path to the USB device ("/dev/bus/usb/$bus/$dev") but more importantly, since QEMU uses qemu_open() for this attribute it allows us to pass pre-opened FD and have QEMU not bother with opening the file at all. The attribute was added in v5.1.0-rc0~71^2~1 QEMU commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-09-09 09:13:52 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsUSBHost[] = {
{ "hostdevice", QEMU_CAPS_USB_HOST_HOSTDEVICE, NULL },
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsSpaprPCIHostBridge[] = {
{ "numa_node", QEMU_CAPS_SPAPR_PCI_HOST_BRIDGE_NUMA_NODE, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVirtioSCSI[] = {
{ "iothread", QEMU_CAPS_VIRTIO_SCSI_IOTHREAD, NULL },
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY, NULL },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM, NULL },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS, NULL },
{ "packed", QEMU_CAPS_VIRTIO_PACKED_QUEUES, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVfioPCI[] = {
{ "display", QEMU_CAPS_VFIO_PCI_DISPLAY, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsSCSIDisk[] = {
{ "channel", QEMU_CAPS_SCSI_DISK_CHANNEL, NULL },
{ "wwn", QEMU_CAPS_SCSI_DISK_WWN, NULL },
{ "share-rw", QEMU_CAPS_DISK_SHARE_RW, NULL },
{ "write-cache", QEMU_CAPS_DISK_WRITE_CACHE, NULL },
{ "device_id", QEMU_CAPS_SCSI_DISK_DEVICE_ID, NULL },
{ "werror", QEMU_CAPS_STORAGE_WERROR, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsIDEDrive[] = {
{ "wwn", QEMU_CAPS_IDE_DRIVE_WWN, NULL },
{ "share-rw", QEMU_CAPS_DISK_SHARE_RW, NULL },
{ "write-cache", QEMU_CAPS_DISK_WRITE_CACHE, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsPiix4PM[] = {
{ "disable_s3", QEMU_CAPS_PIIX_DISABLE_S3, NULL },
{ "disable_s4", QEMU_CAPS_PIIX_DISABLE_S4, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsUSBRedir[] = {
{ "filter", QEMU_CAPS_USB_REDIR_FILTER, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsI440FXPCIHost[] = {
{ "pci-hole64-size", QEMU_CAPS_I440FX_PCI_HOLE64_SIZE, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsQ35PCIHost[] = {
{ "pci-hole64-size", QEMU_CAPS_Q35_PCI_HOLE64_SIZE, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsUSBStorage[] = {
{ "removable", QEMU_CAPS_USB_STORAGE_REMOVABLE, NULL },
{ "share-rw", QEMU_CAPS_DISK_SHARE_RW, NULL },
{ "write-cache", QEMU_CAPS_DISK_WRITE_CACHE, NULL },
{ "werror", QEMU_CAPS_USB_STORAGE_WERROR, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsKVMPit[] = {
{ "lost_tick_policy", QEMU_CAPS_KVM_PIT_TICK_POLICY, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVGA[] = {
{ "vgamem_mb", QEMU_CAPS_VGA_VGAMEM, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVmwareSvga[] = {
{ "vgamem_mb", QEMU_CAPS_VMWARE_SVGA_VGAMEM, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsQxl[] = {
{ "vgamem_mb", QEMU_CAPS_QXL_VGAMEM, NULL },
{ "vram64_size_mb", QEMU_CAPS_QXL_VRAM64, NULL },
{ "max_outputs", QEMU_CAPS_QXL_MAX_OUTPUTS, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVirtioGpu[] = {
{ "virgl", QEMU_CAPS_VIRTIO_GPU_VIRGL, NULL },
{ "max_outputs", QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS, NULL },
{ "disable-legacy", QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY, NULL },
{ "iommu_platform", QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM, NULL },
{ "ats", QEMU_CAPS_VIRTIO_PCI_ATS, NULL },
{ "packed", QEMU_CAPS_VIRTIO_PACKED_QUEUES, NULL },
qemu: caps: check for q35/ICH9 disable S3/S4 Update test data to match
2016-01-09 20:58:50 +00:00
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsICH9[] = {
{ "disable_s3", QEMU_CAPS_ICH9_DISABLE_S3, NULL },
{ "disable_s4", QEMU_CAPS_ICH9_DISABLE_S4, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsUSBNECXHCI[] = {
{ "p3", QEMU_CAPS_NEC_USB_XHCI_PORTS, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsIntelIOMMU[] = {
{ "intremap", QEMU_CAPS_INTEL_IOMMU_INTREMAP, NULL },
{ "caching-mode", QEMU_CAPS_INTEL_IOMMU_CACHING_MODE, NULL },
{ "eim", QEMU_CAPS_INTEL_IOMMU_EIM, NULL },
{ "device-iotlb", QEMU_CAPS_INTEL_IOMMU_DEVICE_IOTLB, NULL },
qemu: format address wdith on intel-iommu command line Format the address width attribute. Depending on the version of QEMU it is named 'aw-bits' or 'x-aw-bits'. Signed-off-by: Menno Lageman <menno.lageman@oracle.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-04 07:42:43 +00:00
{ "aw-bits", QEMU_CAPS_INTEL_IOMMU_AW_BITS, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsObjectPropsVirtualCSSBridge[] = {
{ "cssid-unrestricted", QEMU_CAPS_CCW_CSSID_UNRESTRICTED, NULL },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsMCH[] = {
{ "extended-tseg-mbytes", QEMU_CAPS_MCH_EXTENDED_TSEG_MBYTES, NULL },
};
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsNVDIMM[] = {
{ "unarmed", QEMU_CAPS_DEVICE_NVDIMM_UNARMED, NULL },
qemu: Introduce QEMU_CAPS_DEVICE_NVDIMM_UNARMED capability This capability tracks if nvdimm has the unarmed attribute or not for the nvdimm readonly xml attribute. Signed-off-by: Luyao Zhong <luyao.zhong@intel.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-12-20 09:14:45 +00:00
};
qemu: add QEMU_CAPS_VHOST_USER_FS_BOOTINDEX Introduced by QEMU commit: commit 6da32fe5efdd71c9d254a436ce972194ff631285 Author: Laszlo Ersek <lersek@redhat.com> AuthorDate: 2021-01-12 14:16:03 +0100 Commit: Michael S. Tsirkin <mst@redhat.com> CommitDate: 2021-01-13 09:06:37 -0500 vhost-user-fs: add the "bootindex" property Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-01-04 15:03:57 +00:00
static struct virQEMUCapsDevicePropsFlags virQEMUCapsDevicePropsVhostUserFS[] = {
{ "bootindex", QEMU_CAPS_VHOST_USER_FS_BOOTINDEX, NULL },
};
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: Detect whether iothread polling is supported Add a capability check for IOThread polling (all were added at the same time, so only one check is necessary). Based on code originally posted by Pavel Hrdina <phrdina@redhat.com> with the only changes to include the more recent QEMU releases. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-10-05 19:59:49 +00:00
{ "query-iothreads/ret-type/poll-max-ns", QEMU_CAPS_IOTHREAD_POLLING },
qemu: caps: Introduce QEMU_EGL_HEADLESS_RENDERNODE capability Now that we have QAPI introspection of display types in QEMU upstream, we can check whether the 'rendernode' option is supported with egl-headless display type. Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-11-21 13:07:01 +00:00
{ "query-display-options/ret-type/+egl-headless/rendernode", QEMU_CAPS_EGL_HEADLESS_RENDERNODE },
backup: Add two new qemu capabilities Add two capabilities for testing features required for the upcoming virDomainBackupBegin: use block-dirty-bitmap-merge as the generic witness of bitmap support needed for checkpoints (since all of the bitmap management functionalities were finalized in the same qemu 4.0 release), and the bitmap parameter to nbd-server-add for pull-mode backup support. Even though both capabilities are likely to be present or absent together (that is, it is unlikely to encounter a qemu that backports only one of the two), it still makes sense to keep two capabilities as the two uses are orthogonal (full backups don't require checkpoints, push mode backups don't require NBD bitmap support, and checkpoints can be used for more than just incremental backups). Existing code is not affected by the new capabilities. Signed-off-by: Eric Blake <eblake@redhat.com> Acked-by: Peter Krempa <pkrempa@redhat.com>
2019-06-06 02:25:05 +00:00
{ "nbd-server-add/arg-type/bitmap", QEMU_CAPS_NBD_BITMAP },
qemu: Check for drop-cache capability QEMU 4.0.0 and newer automatically drops caches at the end of migration. Let's check for this capability so that we can allow migration when disk cache is turned on. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Acked-By: Peter Krempa <pkrempa@redhat.com>
2019-08-13 13:17:36 +00:00
{ "blockdev-add/arg-type/+file/drop-cache", QEMU_CAPS_MIGRATION_FILE_DROP_CACHE },
qemu: caps: Add capability for dynamic 'auto-read-only' support for files Initial implementation of 'auto-read-only' didn't reopen the backing files when needed. For '-blockdev' to work we need to be able to tel qemu to open a file read-only and change it during blockjobs as we label backing chains with a sVirt label which does not allow writing. The dynamic auto-read-only supports this as it reopens files when writing is demanded. Add a capability to detect that the posix file based backends support the dynamic part. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-08 15:10:37 +00:00
{ "blockdev-add/arg-type/+file/$dynamic-auto-read-only", QEMU_CAPS_BLOCK_FILE_AUTO_READONLY_DYNAMIC },
qemu: capabilities: Add detection of the 'savevm' fix for -blockdev The 'savevm' HMP command didn't work properly with blockdev as it tried to do snapshot of everything including the protocol nodes accessing files which are not snapshottable. Qemu fixed this bug so now we need to detect it to allow enabling blockdev. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-17 15:10:08 +00:00
{ "human-monitor-command/$savevm-monitor-nodes", QEMU_CAPS_SAVEVM_MONITOR_NODES },
qemu_capabilities: Introduce QEMU_CAPS_DRIVE_NVME This capability tracks if qemu is capable of: -drive file.driver=nvme The feature was added in QEMU's commit of v2.12.0-rc0~104^2~2. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-06-05 14:11:03 +00:00
{ "blockdev-add/arg-type/+nvme", QEMU_CAPS_DRIVE_NVME },
qemu: capabilities: Add capability for the 'flat' argument of 'query-named-block-nodes' Detect the presence of the flag and make it available internally as QEMU_CAPS_QMP_QUERY_NAMED_BLOCK_NODES_FLAT. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-01-21 14:13:47 +00:00
{ "query-named-block-nodes/arg-type/flat", QEMU_CAPS_QMP_QUERY_NAMED_BLOCK_NODES_FLAT },
qemu: capabilities: Introduce QEMU_CAPS_BLOCKDEV_SNAPSHOT_ALLOW_WRITE_ONLY The capability is based on qemu's support of using blockdev-snapshot to install backing chain also for images which are in use by a block-copy job. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2020-03-05 13:28:50 +00:00
{ "blockdev-snapshot/$allow-write-only-overlay", QEMU_CAPS_BLOCKDEV_SNAPSHOT_ALLOW_WRITE_ONLY },
qemu_capabilities: Introduce QEMU_CAPS_AIO_IO_URING Add io_uring value to capability replies. The capability QEMU_CAPS_AIO_IO_URING will be used for io_uring aio mode, introduced from QEMU 5.0, linux 5.1. Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-04-21 12:19:34 +00:00
{ "blockdev-add/arg-type/+file/aio/^io_uring", QEMU_CAPS_AIO_IO_URING },
qemu: Probe for a few params supported by migrate-set-parameters These parameters were originally set via dedicated commands which are now deprecated. We want to use migrate-set-parameters instead if possible. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-06-10 13:09:00 +00:00
{ "migrate-set-parameters/arg-type/max-bandwidth", QEMU_CAPS_MIGRATION_PARAM_BANDWIDTH },
{ "migrate-set-parameters/arg-type/downtime-limit", QEMU_CAPS_MIGRATION_PARAM_DOWNTIME },
{ "migrate-set-parameters/arg-type/xbzrle-cache-size", QEMU_CAPS_MIGRATION_PARAM_XBZRLE_CACHE_SIZE },
qemu: Introduce QEMU_CAPS_NUMA_HMAT capability This capability tracks whether QEMU is capable of defining HMAT ACPI table for the guest. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-27 09:00:07 +00:00
{ "set-numa-node/arg-type/+hmat-lb", QEMU_CAPS_NUMA_HMAT },
qemu: add vhost-vdpa capability Recent versions of qemu added the -netdev vhost-vdpa device. This capability allows libvirt to know whether this is supported. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
2020-10-14 17:08:26 +00:00
{ "netdev_add/arg-type/+vhost-vdpa", QEMU_CAPS_NETDEV_VHOST_VDPA },
qemu: capabilities: Introduce QEMU_CAPS_MIGRATION_PARAM_BLOCK_BITMAP_MAPPING The capability represents qemu's ability to setup mappings for migrating block dirty bitmaps and is based on presence of the 'transform' property of the 'block-bitmap-mapping' property of 'migrate-set-parameters' QMP command. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2020-08-07 09:29:18 +00:00
{ "migrate-set-parameters/arg-type/block-bitmap-mapping/bitmaps/transform",
QEMU_CAPS_MIGRATION_PARAM_BLOCK_BITMAP_MAPPING },
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
};
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
typedef struct _virQEMUCapsDeviceTypeProps virQEMUCapsDeviceTypeProps;
struct _virQEMUCapsDeviceTypeProps {
const char *type;
struct virQEMUCapsDevicePropsFlags *props;
size_t nprops;
int capsCondition;
};
static virQEMUCapsDeviceTypeProps 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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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: Probe caps for 'scsi-hd' instead of 'scsi-disk' Since commit 02e8d0cfdf8 we are using 'scsi-hd' and 'scsi-cd' instead of 'scsi-disk'. We also should probe capabilities for 'scsi-hd' instead of 'scsi-disk'. It is safe to do as 'scsi-disk' is the common denominator of both 'scsi-hd' and 'scsi-cd' so all the properties were common. For now the test data are modified by just changing the appropriate type when probing for caps. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-01-28 09:03:25 +00:00
{ "scsi-hd", virQEMUCapsDevicePropsSCSIDisk,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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: Probe caps for 'ide-hd' instead of 'ide-drive' Since commit a4cda054e7 we are using 'ide-hd' and 'ide-cd' instead of 'ide-drive'. We also should probe capabilities for 'ide-hd' instead of 'ide-drive'. It is safe to do as 'ide-drive' is the common denominator of both 'ide-hd' and 'ide-cd' so all the properties were common. For now the test data are modified by just changing the appropriate type when probing for caps. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-01-28 13:52:22 +00:00
{ "ide-hd", virQEMUCapsDevicePropsIDEDrive,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsObjectPropsVirtualCSSBridge),
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
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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsDevicePropsMCH),
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
QEMU_CAPS_DEVICE_MCH },
qemu: Introduce QEMU_CAPS_DEVICE_NVDIMM_UNARMED capability This capability tracks if nvdimm has the unarmed attribute or not for the nvdimm readonly xml attribute. Signed-off-by: Luyao Zhong <luyao.zhong@intel.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-12-20 09:14:45 +00:00
{ "nvdimm", virQEMUCapsDevicePropsNVDIMM,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsDevicePropsNVDIMM),
qemu: Introduce QEMU_CAPS_DEVICE_NVDIMM_UNARMED capability This capability tracks if nvdimm has the unarmed attribute or not for the nvdimm readonly xml attribute. Signed-off-by: Luyao Zhong <luyao.zhong@intel.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-12-20 09:14:45 +00:00
QEMU_CAPS_DEVICE_NVDIMM },
qemu: new capabilities flag pcie-root-port.hotplug This caps flag is set when the qemu binary supports the option "hotplug" for pcie-root-port, ioh3420 (Intel pcie-root-port) and xio3130-downstream (Intel pcie-downstream-port). If it's available, it's possible to disable hotplugging/unplugging devices on a particular port by adding ",hotplug=off" to the qemu device commandline. This option first appears in qemu-5.0.0. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-02-27 20:22:59 +00:00
{ "pcie-root-port", virQEMUCapsDevicePropsPCIeRootPort,
G_N_ELEMENTS(virQEMUCapsDevicePropsPCIeRootPort),
QEMU_CAPS_DEVICE_PCIE_ROOT_PORT },
qemu_capabilities: Add QEMU_CAPS_USB_HOST_HOSTDEVICE This capability tracks whether "usb-host" device has "hostdevice" attribute. This attribute allows us to specify full path to the USB device ("/dev/bus/usb/$bus/$dev") but more importantly, since QEMU uses qemu_open() for this attribute it allows us to pass pre-opened FD and have QEMU not bother with opening the file at all. The attribute was added in v5.1.0-rc0~71^2~1 QEMU commit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-09-09 09:13:52 +00:00
{ "usb-host", virQEMUCapsDevicePropsUSBHost,
G_N_ELEMENTS(virQEMUCapsDevicePropsUSBHost),
-1 },
qemu: add QEMU_CAPS_VHOST_USER_FS_BOOTINDEX Introduced by QEMU commit: commit 6da32fe5efdd71c9d254a436ce972194ff631285 Author: Laszlo Ersek <lersek@redhat.com> AuthorDate: 2021-01-12 14:16:03 +0100 Commit: Michael S. Tsirkin <mst@redhat.com> CommitDate: 2021-01-13 09:06:37 -0500 vhost-user-fs: add the "bootindex" property Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-01-04 15:03:57 +00:00
{ "vhost-user-fs-device", virQEMUCapsDevicePropsVhostUserFS,
G_N_ELEMENTS(virQEMUCapsDevicePropsVhostUserFS),
QEMU_CAPS_DEVICE_VHOST_USER_FS },
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: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_ALIGN capability This capability tracks if memory-backend-file has the align attribute or not. Signed-off-by: Luyao Zhong <luyao.zhong@intel.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-12-20 09:14:43 +00:00
{ "align", QEMU_CAPS_OBJECT_MEMORY_FILE_ALIGN },
qemu: Introduce QEMU_CAPS_OBJECT_MEMORY_FILE_PMEM capability This capability tracks if memory-backend-file has the pmem attribute or not. Signed-off-by: Luyao Zhong <luyao.zhong@intel.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-12-20 09:14:44 +00:00
{ "pmem", QEMU_CAPS_OBJECT_MEMORY_FILE_PMEM },
qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID This capability tracks whether memory-backend-file has "x-use-canonical-path-for-ramblock-id" attribute. Introduced into QEMU by commit fa0cb34d2210cc749b9a70db99bb41c56ad20831. As of QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9 the property is considered stable by qemu despite the 'x-' prefix to preserve compatibility with released qemu versions. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-01-11 17:15:57 +00:00
/* As of QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9 the
* "x-use-canonical-path-for-ramblock-id" property is considered stable and
* supported. The 'x-' prefix was kept for compatibility with already
* released qemu versions. */
{ "x-use-canonical-path-for-ramblock-id", QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID },
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
};
qemu: check memory-backend-memfd.hugetlb capability QEMU 3.1 should only expose the property if the host is actually capable of creating hugetable-backed memfd. However, it may fail at runtime depending on requested "hugetlbsize". Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-15 11:55:52 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsMemoryBackendMemfd[] = {
{ "hugetlb", QEMU_CAPS_OBJECT_MEMORY_MEMFD_HUGETLB },
};
qemu: Rename virQEMUCapsObjectPropsMaxX86CPU We're going to use it on non-x86 soon, so it needs a more generic name: virQEMUCapsObjectPropsMaxCPU. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-07-08 11:14:53 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsMaxCPU[] = {
qemu: Probe for "unavailable-features" CPU property It is similar to "filtered-features" property, which reports CPUID bits corresponding to disabled features, but more general. The "unavailable-features" property supports both CPUID and MSR features by listing their names. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-10 14:49:22 +00:00
{ "unavailable-features", QEMU_CAPS_CPU_UNAVAILABLE_FEATURES },
qemu: Add the QEMU_CAPS_CPU_KVM_NO_ADJVTIME capability We will use this capability to detect whether the QEMU binary supports the kvm-no-adjvtime CPU feature. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-01-31 13:28:57 +00:00
{ "kvm-no-adjvtime", QEMU_CAPS_CPU_KVM_NO_ADJVTIME },
qemu: Probe for .migratable property of a CPU Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-02 18:15:53 +00:00
{ "migratable", QEMU_CAPS_CPU_MIGRATABLE },
qemu: Probe for "unavailable-features" CPU property It is similar to "filtered-features" property, which reports CPUID bits corresponding to disabled features, but more general. The "unavailable-features" property supports both CPUID and MSR features by listing their names. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-10 14:49:22 +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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsObjectPropsMemoryBackendFile),
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
QEMU_CAPS_OBJECT_MEMORY_FILE },
qemu: check memory-backend-memfd.hugetlb capability QEMU 3.1 should only expose the property if the host is actually capable of creating hugetable-backed memfd. However, it may fail at runtime depending on requested "hugetlbsize". Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-15 11:55:52 +00:00
{ "memory-backend-memfd", virQEMUCapsObjectPropsMemoryBackendMemfd,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsObjectPropsMemoryBackendMemfd),
qemu: check memory-backend-memfd.hugetlb capability QEMU 3.1 should only expose the property if the host is actually capable of creating hugetable-backed memfd. However, it may fail at runtime depending on requested "hugetlbsize". Reviewed-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: John Ferlan <jferlan@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-15 11:55:52 +00:00
QEMU_CAPS_OBJECT_MEMORY_MEMFD },
qemu: Rename virQEMUCapsObjectPropsMaxX86CPU We're going to use it on non-x86 soon, so it needs a more generic name: virQEMUCapsObjectPropsMaxCPU. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-07-08 11:14:53 +00:00
{ "max-x86_64-cpu", virQEMUCapsObjectPropsMaxCPU,
G_N_ELEMENTS(virQEMUCapsObjectPropsMaxCPU),
qemu: Probe for "unavailable-features" CPU property It is similar to "filtered-features" property, which reports CPUID bits corresponding to disabled features, but more general. The "unavailable-features" property supports both CPUID and MSR features by listing their names. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-10 14:49:22 +00:00
QEMU_CAPS_X86_MAX_CPU },
qemu: Query max-arm-cpu properties Signed-off-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-07-08 11:46:37 +00:00
{ "max-arm-cpu", virQEMUCapsObjectPropsMaxCPU,
G_N_ELEMENTS(virQEMUCapsObjectPropsMaxCPU),
QEMU_CAPS_ARM_MAX_CPU },
qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:45:08 +00:00
};
qemu: Probe canonicalized machine type Now that we have the list of machine types available when probing machine type properties, we can list properties for the canonicalized version of the "pseries" machine type instead of having to go through "spapr-machine", which we know to be the parent type for all "pseries-*-machine" types. By doing this, we'll be able to find even properties that are only available from a certain versioned machine type forward, and can't thus be obtained when looking at the parent type only. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 08:34:01 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsMachinePropsPSeries[] = {
qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:45:08 +00:00
{ "cap-hpt-max-page-size", QEMU_CAPS_MACHINE_PSERIES_CAP_HPT_MAX_PAGE_SIZE },
{ "cap-htm", QEMU_CAPS_MACHINE_PSERIES_CAP_HTM },
{ "cap-nested-hv", QEMU_CAPS_MACHINE_PSERIES_CAP_NESTED_HV },
qemu: Add capability for the ccf-assist pSeries feature Linux kernel 5.1 added a new PPC KVM capability named KVM_PPC_CPU_CHAR_BCCTR_FLUSH_ASSIST, which is exposed to the QEMU guest since QEMU commit 8ff43ee404d under a new sPAPR capability called SPAPR_CAP_CCF_ASSIST. This cap indicates whether the processor supports hardware acceleration for the count cache flush workaround, which is a software workaround that flushes the count cache on context switch. If the processor has this hardware acceleration, the software flush can be shortened, resulting in performance gain. This hardware acceleration is defaulted to 'off' in QEMU. The reason is that earlier versions of the Power 9 processor didn't support it (it is available on Power 9 DD2.3 and newer), and defaulting this option to 'on' would break migration compatibility between the Power 9 processor class. However, the user running a P9 DD2.3+ hypervisor might want to create guests with ccf-assist=on, accepting the downside of only being able to migrate them only between other P9 DD2.3+ hosts running upstream kernel 5.1+, to get a performance boost. This patch adds this new capability to Libvirt, with the name of QEMU_CAPS_MACHINE_PSERIES_CAP_CCF_ASSIST. Reviewed-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-10-08 20:06:23 +00:00
{ "cap-ccf-assist", QEMU_CAPS_MACHINE_PSERIES_CAP_CCF_ASSIST },
qemu: Add capability for CFPC pSeries feature CFPC (Cache Flush on Privilege Change) is one of the capabilities added to QEMU to mitigate Spectre vulnerabilities in Power chips. It was implemented in QEMU 2.12 by commit 6898aed77f46. This capability is still used today due to differences in how the host setup (hardware and firmware/kernel) can handle this mitigation. Its default value also varies with the pseries machine version of the time. There's also certain OSes, like AIX, that might not support the default value of the pseries machine the guest uses. Exposing this in the Libvirt XML as a feature will allow users to tune CFPC values in a cleaner way, instead of hacking parameters in <qemu:commandline> elements. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 12:14:26 +00:00
{ "cap-cfpc", QEMU_CAPS_MACHINE_PSERIES_CAP_CFPC },
qemu: Add capability for SBBC pSeries feature SBBC (Speculation Barrier Bounds Checking) is another capability related to Spectre mitigation efforts in Power processors. It was implemented in QEMU 2.12 by commit 09114fd81799. This patch introduces it as QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC to be implemented in the next patch. Like the case with the now implemented CFPC, exposing this feature in the XML allows for a cleaner way for users to tune the SBBC accordingly, given that not all hypervisor and guest setups supports this Spectre mitigation. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 12:14:28 +00:00
{ "cap-sbbc", QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC },
qemu: Add capability for IBS pSeries feature IBS (Indirect Branch Speculation) is the last capability added in QEMU 2.12 related to Spectre mitigation for Power. It was added in commit 4be8d4e7d935. This patch introduces it as QEMU_CAPS_MACHINE_PSERIES_CAP_IBS. Like CFPC and SBBC, users might want to tune in IBS based on their HW and guest OS requirements, and it's better to do it so in a proper Libvirt feature than to put QEMU arguments in the middle of the domain XML. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 12:14:30 +00:00
{ "cap-ibs", QEMU_CAPS_MACHINE_PSERIES_CAP_IBS },
qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:45:08 +00:00
};
qemu: Introduce QEMU_CAPS_MACHINE_VIRT_IOMMU This capability can be used to figure out whether the QEMU binary at hand supports the machine type property we need in order to enable SMMUv3 IOMMU support. Unfortunately we can't avoid probing the RISC-V binaries along with the ARM ones, since both architectures have their own 'virt' machine type. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-05-17 07:15:27 +00:00
static struct virQEMUCapsStringFlags virQEMUCapsMachinePropsVirt[] = {
{ "iommu", QEMU_CAPS_MACHINE_VIRT_IOMMU },
};
qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:45:08 +00:00
static virQEMUCapsObjectTypeProps virQEMUCapsMachineProps[] = {
qemu: Probe canonicalized machine type Now that we have the list of machine types available when probing machine type properties, we can list properties for the canonicalized version of the "pseries" machine type instead of having to go through "spapr-machine", which we know to be the parent type for all "pseries-*-machine" types. By doing this, we'll be able to find even properties that are only available from a certain versioned machine type forward, and can't thus be obtained when looking at the parent type only. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 08:34:01 +00:00
{ "pseries", virQEMUCapsMachinePropsPSeries,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsMachinePropsPSeries),
qemu: Add capability for the HPT maxpagesize feature Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-06-19 11:51:05 +00:00
-1 },
qemu: Introduce QEMU_CAPS_MACHINE_VIRT_IOMMU This capability can be used to figure out whether the QEMU binary at hand supports the machine type property we need in order to enable SMMUv3 IOMMU support. Unfortunately we can't avoid probing the RISC-V binaries along with the ARM ones, since both architectures have their own 'virt' machine type. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-05-17 07:15:27 +00:00
{ "virt", virQEMUCapsMachinePropsVirt,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsMachinePropsVirt),
qemu: Introduce QEMU_CAPS_MACHINE_VIRT_IOMMU This capability can be used to figure out whether the QEMU binary at hand supports the machine type property we need in order to enable SMMUv3 IOMMU support. Unfortunately we can't avoid probing the RISC-V binaries along with the ARM ones, since both architectures have their own 'virt' machine type. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-05-17 07:15:27 +00:00
-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
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;
qemu: add explicit flag to skip qemu caps invalidation Currently if the binary path is NULL in the qemu capabilities object, cache invalidation is skipped. A future patch will ensure that the binary path is always non-NULL, so a way to explicitly skip invalidation is required. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 11:56:38 +00:00
qemuCaps->invalidation = true;
virBitmapNew: Don't check return value Remove return value check from all callers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-10-01 15:42:11 +00:00
qemuCaps->flags = virBitmapNew(QEMU_CAPS_LAST);
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;
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: add qemu caps constructor which takes binary name Simplify repeated code patterns by providing a new constructor taking the QEMU binary name. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 12:28:57 +00:00
virQEMUCapsPtr
virQEMUCapsNewBinary(const char *binary)
{
virQEMUCapsPtr qemuCaps = virQEMUCapsNew();
virQEMUCapsNewBinary: Avoid NULL dereference Even with GLib it is still possible for virQEMUCapsNew() to return NULL because it calls virQEMUCapsInitialize() which is a wrapper over pthread_once() which may fail. At least, we still check for its retval. If it so happens that the virQEMUCapsNew() fails and returns NULL, we should not dereference it. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-30 08:56:08 +00:00
if (qemuCaps)
qemuCaps->binary = g_strdup(binary);
qemu: add qemu caps constructor which takes binary name Simplify repeated code patterns by providing a new constructor taking the QEMU binary name. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 12:28:57 +00:00
return qemuCaps;
}
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)
{
Use g_autoptr instead of VIR_AUTOPTR Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOPTR aliases to g_autoptr. Replace all of its use by the GLib macro version. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 12:47:50 +00:00
g_autoptr(virSEVCapability) tmp = NULL;
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
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
tmp = g_new0(virSEVCapability, 1);
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
qemu: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
tmp->pdh = g_strdup(src->pdh);
tmp->cert_chain = g_strdup(src->cert_chain);
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
tmp->cbitpos = src->cbitpos;
tmp->reduced_phys_bits = src->reduced_phys_bits;
qemu: use g_steal_pointer instead of VIR_STEAL_PTR Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-16 11:43:18 +00:00
*dst = g_steal_pointer(&tmp);
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
return 0;
}
qemu: Introduce virQEMUCapsCopyMachineTypes The function copies machine type data from one QEMU caps structure to another. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 09:35:10 +00:00
static void
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsAccelCopyMachineTypes(virQEMUCapsAccelPtr dst,
virQEMUCapsAccelPtr src)
qemu: Introduce virQEMUCapsCopyMachineTypes The function copies machine type data from one QEMU caps structure to another. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 09:35:10 +00:00
{
size_t i;
dst->machineTypes = g_new0(virQEMUCapsMachineType, src->nmachineTypes);
dst->nmachineTypes = src->nmachineTypes;
for (i = 0; i < src->nmachineTypes; i++) {
dst->machineTypes[i].name = g_strdup(src->machineTypes[i].name);
dst->machineTypes[i].alias = g_strdup(src->machineTypes[i].alias);
qemu: Probe for default CPU types QEMU 4.2.0 will report default CPU types used by each machine type and we will want to start using it. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-07-18 17:21:55 +00:00
dst->machineTypes[i].defaultCPU = g_strdup(src->machineTypes[i].defaultCPU);
qemu: Introduce virQEMUCapsCopyMachineTypes The function copies machine type data from one QEMU caps structure to another. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 09:35:10 +00:00
dst->machineTypes[i].maxCpus = src->machineTypes[i].maxCpus;
dst->machineTypes[i].hotplugCpus = src->machineTypes[i].hotplugCpus;
dst->machineTypes[i].qemuDefault = src->machineTypes[i].qemuDefault;
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
dst->machineTypes[i].numaMemSupported = src->machineTypes[i].numaMemSupported;
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
dst->machineTypes[i].defaultRAMid = g_strdup(src->machineTypes[i].defaultRAMid);
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
dst->machineTypes[i].deprecated = src->machineTypes[i].deprecated;
qemu: Introduce virQEMUCapsCopyMachineTypes The function copies machine type data from one QEMU caps structure to another. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 09:35:10 +00:00
}
}
qemu: Introduce virQEMUCapsAccelCopy Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:41:31 +00:00
static int
virQEMUCapsAccelCopy(virQEMUCapsAccelPtr dst,
virQEMUCapsAccelPtr src)
{
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsAccelCopyMachineTypes(dst, src);
qemu: Introduce virQEMUCapsAccelCopy Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:41:31 +00:00
if (virQEMUCapsHostCPUDataCopy(&dst->hostCPU, &src->hostCPU) < 0)
return -1;
dst->cpuModels = qemuMonitorCPUDefsCopy(src->cpuModels);
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
{
qemu: add qemu caps constructor which takes binary name Simplify repeated code patterns by providing a new constructor taking the QEMU binary name. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 12:28:57 +00:00
virQEMUCapsPtr ret = virQEMUCapsNewBinary(qemuCaps->binary);
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: add explicit flag to skip qemu caps invalidation Currently if the binary path is NULL in the qemu capabilities object, cache invalidation is skipped. A future patch will ensure that the binary path is always non-NULL, so a way to explicitly skip invalidation is required. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 11:56:38 +00:00
ret->invalidation = qemuCaps->invalidation;
qemu: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
ret->kvmSupportsNesting = qemuCaps->kvmSupportsNesting;
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
ret->kvmSupportsSecureGuest = qemuCaps->kvmSupportsSecureGuest;
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
qemu: Copy missing QEMU caps elements Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-04 14:48:40 +00:00
ret->ctime = qemuCaps->ctime;
Use 'virBitmapNewCopy' instead of 'virBitmapCopy' There are only 3 places using the function. Two can use virBitmapNewCopy directly. In case of the qemu capabilities code we need to free the old bitmap first. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-10-02 08:26:34 +00:00
virBitmapFree(ret->flags);
ret->flags = virBitmapNewCopy(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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
ret->hostCPUSignature = g_strdup(qemuCaps->hostCPUSignature);
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: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
ret->package = g_strdup(qemuCaps->package);
ret->kernelVersion = g_strdup(qemuCaps->kernelVersion);
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
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: Introduce virQEMUCapsAccelCopy Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:41:31 +00:00
if (virQEMUCapsAccelCopy(&ret->kvm, &qemuCaps->kvm) < 0 ||
virQEMUCapsAccelCopy(&ret->tcg, &qemuCaps->tcg) < 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;
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
ret->gicCapabilities = g_new0(virGICCapability, qemuCaps->ngicCapabilities);
qemu: Copy missing QEMU caps elements Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-04 14:48:40 +00:00
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;
}
qemu: Introduce virQEMUCapsAccelClear Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:42:54 +00:00
static void
virQEMUCapsAccelClear(virQEMUCapsAccelPtr caps)
{
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
size_t i;
for (i = 0; i < caps->nmachineTypes; i++) {
VIR_FREE(caps->machineTypes[i].name);
VIR_FREE(caps->machineTypes[i].alias);
qemu: Probe for default CPU types QEMU 4.2.0 will report default CPU types used by each machine type and we will want to start using it. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-07-18 17:21:55 +00:00
VIR_FREE(caps->machineTypes[i].defaultCPU);
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
VIR_FREE(caps->machineTypes[i].defaultRAMid);
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
}
VIR_FREE(caps->machineTypes);
qemu: Introduce virQEMUCapsAccelClear Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:42:54 +00:00
virQEMUCapsHostCPUDataClear(&caps->hostCPU);
qemu_capabilities: Use proper free function for caps->cpuModels The cpuModels member of _virQEMUCapsAccel struct is not a virObject but regular struct with a free function defined: qemuMonitorCPUDefsFree(). Use that when clearing parent structure instead of virObjectUnref() to avoid a memleak: ==212322== 57,275 (48 direct, 57,227 indirect) bytes in 3 blocks are definitely lost in loss record 623 of 627 ==212322== at 0x4838B86: calloc (vg_replace_malloc.c:762) ==212322== by 0x554A158: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.6) ==212322== by 0x17B14BF5: qemuMonitorCPUDefsNew (qemu_monitor.c:3587) ==212322== by 0x17B27BA7: qemuMonitorJSONGetCPUDefinitions (qemu_monitor_json.c:5616) ==212322== by 0x17B14B0B: qemuMonitorGetCPUDefinitions (qemu_monitor.c:3559) ==212322== by 0x17A6AFBB: virQEMUCapsFetchCPUDefinitions (qemu_capabilities.c:2571) ==212322== by 0x17A6B2CC: virQEMUCapsProbeQMPCPUDefinitions (qemu_capabilities.c:2629) ==212322== by 0x17A70C00: virQEMUCapsInitQMPMonitorTCG (qemu_capabilities.c:4769) ==212322== by 0x17A70DDF: virQEMUCapsInitQMPSingle (qemu_capabilities.c:4820) ==212322== by 0x17A70E99: virQEMUCapsInitQMP (qemu_capabilities.c:4848) ==212322== by 0x17A71044: virQEMUCapsNewForBinaryInternal (qemu_capabilities.c:4891) ==212322== by 0x17A7119C: virQEMUCapsNewData (qemu_capabilities.c:4923) Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-11-25 15:35:27 +00:00
qemuMonitorCPUDefsFree(caps->cpuModels);
qemu: Introduce virQEMUCapsAccelClear Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:42: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
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
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: replace VIR_FREE with g_free in all *Dispose() functions Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2021-02-03 20:13:53 +00:00
g_free(qemuCaps->package);
g_free(qemuCaps->kernelVersion);
g_free(qemuCaps->binary);
g_free(qemuCaps->hostCPUSignature);
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
qemu: replace VIR_FREE with g_free in all *Dispose() functions Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2021-02-03 20:13:53 +00:00
g_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: Introduce virQEMUCapsAccelClear Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:42:54 +00:00
virQEMUCapsAccelClear(&qemuCaps->kvm);
virQEMUCapsAccelClear(&qemuCaps->tcg);
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
}
qemu: add virQEMUCapsSetVAList And adjust virQEMUCapsSetList to use it. It will also be used in future patches. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-13 19:03:45 +00:00
void
virQEMUCapsSetList(virQEMUCapsPtr qemuCaps, ...)
{
va_list list;
qemu_capabilities; Drop virQEMUCapsSetVAList There is one specific caller (testInfoSetArgs() in qemuxml2argvtest.c) which expect the va_list argument to change after returning from the virQEMUCapsSetVAList() function. However, since we are passing plain va_list this is not guaranteed. The man page of stdarg(3) says: If ap is passed to a function that uses va_arg(ap,type), then the value of ap is undefined after the return of that function. (ap is a variable of type va_list) I've seen this in action in fact: on i686 the qemuxml2argvtest fails on the second test case because testInfoSetArgs() sees ARG_QEMU_CAPS and calls virQEMUCapsSetVAList to process the capabilities (in this case there's just one QEMU_CAPS_SECCOMP_BLACKLIST). But since the changes are not reflected in the caller, in the next iteration testInfoSetArgs() sees the QEMU capability and not ARG_END. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-27 16:19:37 +00:00
int flag;
qemu: add virQEMUCapsSetVAList And adjust virQEMUCapsSetList to use it. It will also be used in future patches. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-13 19:03:45 +00:00
va_start(list, qemuCaps);
qemu_capabilities; Drop virQEMUCapsSetVAList There is one specific caller (testInfoSetArgs() in qemuxml2argvtest.c) which expect the va_list argument to change after returning from the virQEMUCapsSetVAList() function. However, since we are passing plain va_list this is not guaranteed. The man page of stdarg(3) says: If ap is passed to a function that uses va_arg(ap,type), then the value of ap is undefined after the return of that function. (ap is a variable of type va_list) I've seen this in action in fact: on i686 the qemuxml2argvtest fails on the second test case because testInfoSetArgs() sees ARG_QEMU_CAPS and calls virQEMUCapsSetVAList to process the capabilities (in this case there's just one QEMU_CAPS_SECCOMP_BLACKLIST). But since the changes are not reflected in the caller, in the next iteration testInfoSetArgs() sees the QEMU capability and not ARG_END. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-27 16:19:37 +00:00
while ((flag = va_arg(list, int)) < QEMU_CAPS_LAST)
virQEMUCapsSet(qemuCaps, 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
}
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: Enable PCI multi bus for S390 guests QEMU on s390 supports PCI multibus since forever. Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Stefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-11-08 11:00:22 +00:00
/* S390 supports PCI-multibus. */
if (ARCH_IS_S390(def->os.arch))
return true;
qemu: Add PCI support for RISC-V guests virtio-mmio is still used by default, so if PCI is desired it's necessary to explicitly opt-in by adding an appropriate <address type='pci' domain='0x0000' ... /> element to the corresponding device. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-09-21 13:29:38 +00:00
/* If the virt machine, both on ARM and RISC-V, supports PCI,
* then it also supports multibus */
if (qemuDomainIsARMVirt(def) ||
qemuDomainIsRISCVVirt(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 support for RISC-V guests virtio-mmio is still used by default, so if PCI is desired it's necessary to explicitly opt-in by adding an appropriate <address type='pci' domain='0x0000' ... /> element to the corresponding device. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-09-21 13:29:38 +00:00
}
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: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
size_t start;
qemu: Introduce and use virQEMUCapsGetAccel The function can be used to get the pointer to all data which depend on the accelerator. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:46:28 +00:00
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, type);
qemuMonitorCPUDefsPtr defs = accel->cpuModels;
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
if (defs) {
start = defs->ncpus;
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: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
if (VIR_EXPAND_N(defs->cpus, defs->ncpus, count) < 0)
return -1;
} else {
start = 0;
if (!(defs = qemuMonitorCPUDefsNew(count)))
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
return -1;
qemu: Introduce and use virQEMUCapsGetAccel The function can be used to get the pointer to all data which depend on the accelerator. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:46:28 +00:00
accel->cpuModels = defs;
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 < count; i++) {
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
qemuMonitorCPUDefInfoPtr cpu = defs->cpus + start + i;
cpu->usable = usable;
cpu->name = g_strdup(name[i]);
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;
}
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +00:00
static virDomainCapsCPUModelsPtr
virQEMUCapsCPUDefsToModels(qemuMonitorCPUDefsPtr defs,
qemu: remove use of the terms 'whitelist' and 'blacklist' from CPU code When listing CPU models, we need to filter the data based on sets of permitted and forbidden CPU models. Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-16 10:16:43 +00:00
const char **modelAllowed,
const char **modelForbidden)
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +00:00
{
g_autoptr(virDomainCapsCPUModels) cpuModels = NULL;
size_t i;
if (!(cpuModels = virDomainCapsCPUModelsNew(defs->ncpus)))
return NULL;
for (i = 0; i < defs->ncpus; i++) {
qemuMonitorCPUDefInfoPtr cpu = defs->cpus + i;
Replace virStringListHasString by g_strv_contains The glib variant doesn't accept NULL list, but there's just one caller where it wasn't checked explicitly, thus there's no need for our own wrapper. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 17:39:47 +00:00
if (modelAllowed && !g_strv_contains(modelAllowed, cpu->name))
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +00:00
continue;
Replace virStringListHasString by g_strv_contains The glib variant doesn't accept NULL list, but there's just one caller where it wasn't checked explicitly, thus there's no need for our own wrapper. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 17:39:47 +00:00
if (modelForbidden && g_strv_contains(modelForbidden, cpu->name))
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +00:00
continue;
if (virDomainCapsCPUModelsAdd(cpuModels, cpu->name, cpu->usable,
qemu: report whether a CPU model is deprecated in dom capabilities QEMU has the ability to mark CPUs as deprecated. This should be exposed to management applications in the domain capabilities. This attribute is only set when the model is actually deprecated. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 11:15:08 +00:00
cpu->blockers, cpu->deprecated) < 0)
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +00:00
return NULL;
}
return g_steal_pointer(&cpuModels);
}
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: Rename virQEMUCaps{Get,Fetch}CPUDefinitions The functions return virDomainCapsCPUModelsPtr and thus they should be called *CPUModels for consistency. Functions called *CPUDefinitions will work on qemuMonitorCPUDefsPtr. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-09 08:14:59 +00:00
virQEMUCapsGetCPUModels(virQEMUCapsPtr qemuCaps,
virDomainVirtType type,
qemu: remove use of the terms 'whitelist' and 'blacklist' from CPU code When listing CPU models, we need to filter the data based on sets of permitted and forbidden CPU models. Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-16 10:16:43 +00:00
const char **modelAllowed,
const char **modelForbidden)
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: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
qemuMonitorCPUDefsPtr defs;
qemu: Copy CPU models in virQEMUCapsGetCPUDefinitions Rather than returning a direct pointer the list stored in qemuCaps the function now creates a new copy of the CPU models list. The main purpose of this seemingly useless change is to update callers to free the result returned by virQEMUCapsGetCPUDefinitions because the internals of this function will change significantly in the following patches. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-20 20:41:34 +00:00
qemu: Introduce and use virQEMUCapsGetAccel The function can be used to get the pointer to all data which depend on the accelerator. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:46:28 +00:00
if (!(defs = virQEMUCapsGetAccel(qemuCaps, type)->cpuModels))
qemu: Copy CPU models in virQEMUCapsGetCPUDefinitions Rather than returning a direct pointer the list stored in qemuCaps the function now creates a new copy of the CPU models list. The main purpose of this seemingly useless change is to update callers to free the result returned by virQEMUCapsGetCPUDefinitions because the internals of this function will change significantly in the following patches. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-20 20:41:34 +00:00
return NULL;
qemu: remove use of the terms 'whitelist' and 'blacklist' from CPU code When listing CPU models, we need to filter the data based on sets of permitted and forbidden CPU models. Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-16 10:16:43 +00:00
return virQEMUCapsCPUDefsToModels(defs, modelAllowed, modelForbidden);
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: 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: Drop virQEMUCapsGetHostCPUData It was very similar to virQEMUCapsGetAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:57:20 +00:00
virQEMUCapsHostCPUDataPtr cpuData;
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
qemu: Drop virQEMUCapsGetHostCPUData It was very similar to virQEMUCapsGetAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:57:20 +00:00
cpuData = &virQEMUCapsGetAccel(qemuCaps, type)->hostCPU;
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: Drop virQEMUCapsGetHostCPUData It was very similar to virQEMUCapsGetAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:57:20 +00:00
virQEMUCapsHostCPUDataPtr cpuData;
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
qemu: Drop virQEMUCapsGetHostCPUData It was very similar to virQEMUCapsGetAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:57:20 +00:00
cpuData = &virQEMUCapsGetAccel(qemuCaps, type)->hostCPU;
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
}
conf: don't use passed in caps in post parse method To enable the virCapsPtr parameter to the post parse method to be eliminated, the drivers must fetch the virCapsPtr from their own driver via the opaque parameter, or use an alternative approach to validate the parsed data. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-03 10:49:49 +00:00
bool
virQEMUCapsIsArchSupported(virQEMUCapsPtr qemuCaps,
virArch arch)
{
if (arch == qemuCaps->arch)
return true;
if (qemuCaps->arch == VIR_ARCH_X86_64 && arch == VIR_ARCH_I686)
return true;
if (qemuCaps->arch == VIR_ARCH_AARCH64 && arch == VIR_ARCH_ARMV7L)
return true;
if (qemuCaps->arch == VIR_ARCH_ARMV7L && arch == VIR_ARCH_ARMV6L)
return true;
if (qemuCaps->arch == VIR_ARCH_PPC64 && arch == VIR_ARCH_PPC64LE)
return true;
return false;
}
bool
virQEMUCapsIsVirtTypeSupported(virQEMUCapsPtr qemuCaps,
virDomainVirtType virtType)
{
qemu: Fix capabilities probing with TCG Only probe QEMU binary with accel=tcg if TCG is not disabled. Similarly, only add a VIR_DOMAIN_VIRT_QEMU guest if TCG is available. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-22 21:50:42 +00:00
if (virtType == VIR_DOMAIN_VIRT_QEMU &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_TCG))
conf: don't use passed in caps in post parse method To enable the virCapsPtr parameter to the post parse method to be eliminated, the drivers must fetch the virCapsPtr from their own driver via the opaque parameter, or use an alternative approach to validate the parsed data. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-03 10:49:49 +00:00
return true;
if (virtType == VIR_DOMAIN_VIRT_KVM &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
return true;
return false;
}
qemu_capabilities: Disable CPU models on old s390 machine types Starting a KVM domain on s390 with old machine type (such as s390-ccw-virtio-2.5) and without any guest CPU model configured fails with CPU models are not available: KVM doesn't support CPU models QEMU error. This is cause by libvirt using host-model CPU as the default CPU based on QEMU reporting "host" CPU model as being the default one (see commit v5.9.0-402-g24d8202294: qemu: Use host-model CPU on s390 by default). However, even though both QEMU and KVM support CPU models on s390 and QEMU can give us the host-model CPU, we can't use it with old machine types which only support -cpu host. https://bugzilla.redhat.com/show_bug.cgi?id=1795651 Reported-by: Christian Ehrhardt <paelzer@gmail.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-02-06 09:22:23 +00:00
const char *s390HostPassthroughOnlyMachines[] = {
"s390-ccw-virtio-2.4",
"s390-ccw-virtio-2.5",
"s390-ccw-virtio-2.6",
"s390-ccw-virtio-2.7",
NULL
};
conf: don't use passed in caps in post parse method To enable the virCapsPtr parameter to the post parse method to be eliminated, the drivers must fetch the virCapsPtr from their own driver via the opaque parameter, or use an alternative approach to validate the parsed data. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-03 10:49:49 +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,
qemu: cache host arch separately from virCapsPtr As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 17:51:22 +00:00
virArch hostarch,
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
virDomainVirtType type,
qemu: Pass machine type to virQEMUCapsIsCPUModeSupported The usability of a specific CPU mode may depend on machine type, let's prepare for this by passing it to virQEMUCapsIsCPUModeSupported. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-02-05 14:51:09 +00:00
virCPUMode mode,
qemu_capabilities: Disable CPU models on old s390 machine types Starting a KVM domain on s390 with old machine type (such as s390-ccw-virtio-2.5) and without any guest CPU model configured fails with CPU models are not available: KVM doesn't support CPU models QEMU error. This is cause by libvirt using host-model CPU as the default CPU based on QEMU reporting "host" CPU model as being the default one (see commit v5.9.0-402-g24d8202294: qemu: Use host-model CPU on s390 by default). However, even though both QEMU and KVM support CPU models on s390 and QEMU can give us the host-model CPU, we can't use it with old machine types which only support -cpu host. https://bugzilla.redhat.com/show_bug.cgi?id=1795651 Reported-by: Christian Ehrhardt <paelzer@gmail.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-02-06 09:22:23 +00:00
const char *machineType)
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
{
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
qemuMonitorCPUDefsPtr cpus;
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_capabilities: Disable CPU models on old s390 machine types Starting a KVM domain on s390 with old machine type (such as s390-ccw-virtio-2.5) and without any guest CPU model configured fails with CPU models are not available: KVM doesn't support CPU models QEMU error. This is cause by libvirt using host-model CPU as the default CPU based on QEMU reporting "host" CPU model as being the default one (see commit v5.9.0-402-g24d8202294: qemu: Use host-model CPU on s390 by default). However, even though both QEMU and KVM support CPU models on s390 and QEMU can give us the host-model CPU, we can't use it with old machine types which only support -cpu host. https://bugzilla.redhat.com/show_bug.cgi?id=1795651 Reported-by: Christian Ehrhardt <paelzer@gmail.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-02-06 09:22:23 +00:00
/* CPU models (except for "host") are not supported by QEMU for on s390
* KVM domains with old machine types regardless on QEMU version. */
if (ARCH_IS_S390(qemuCaps->arch) &&
type == VIR_DOMAIN_VIRT_KVM &&
mode != VIR_CPU_MODE_HOST_PASSTHROUGH &&
machineType &&
g_strv_contains(s390HostPassthroughOnlyMachines, machineType)) {
return false;
}
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 &&
qemu: cache host arch separately from virCapsPtr As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 17:51:22 +00:00
virQEMUCapsGuestIsNative(hostarch, qemuCaps->arch);
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
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: Introduce and use virQEMUCapsGetAccel The function can be used to get the pointer to all data which depend on the accelerator. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:46:28 +00:00
cpus = virQEMUCapsGetAccel(qemuCaps, type)->cpuModels;
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
return cpus && cpus->ncpus > 0;
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
conf: define a new "maximum" CPU mode For hardware virtualization this is functionally identical to the existing host-passthrough mode so the same caveats apply. For emulated guest this exposes the maximum featureset supported by the emulator. Note that despite being emulated this is not guaranteed to be migration safe, especially if different emulator software versions are used on each host. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-05 15:51:09 +00:00
case VIR_CPU_MODE_MAXIMUM:
qemu: wire up support for maximum CPU model The "max" model can be treated the same way as "host" model in general. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-05 18:35:10 +00:00
return virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_MAX);
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;
}
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.
*/
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
const char *
virQEMUCapsGetCanonicalMachine(virQEMUCapsPtr qemuCaps,
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virDomainVirtType virtType,
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
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
{
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsAccelPtr accel;
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
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
accel = virQEMUCapsGetAccel(qemuCaps, virtType);
for (i = 0; i < accel->nmachineTypes; i++) {
if (!accel->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: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
if (STREQ(accel->machineTypes[i].alias, name))
return accel->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: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
int
virQEMUCapsGetMachineMaxCpus(virQEMUCapsPtr qemuCaps,
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virDomainVirtType virtType,
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
const char *name)
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
{
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsAccelPtr accel;
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
size_t i;
if (!name)
return 0;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
accel = virQEMUCapsGetAccel(qemuCaps, virtType);
for (i = 0; i < accel->nmachineTypes; i++) {
if (!accel->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: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
if (STREQ(accel->machineTypes[i].name, name))
return accel->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: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
bool
virQEMUCapsGetMachineHotplugCpus(virQEMUCapsPtr qemuCaps,
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virDomainVirtType virtType,
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
const char *name)
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
{
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsAccelPtr accel;
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
size_t i;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
accel = virQEMUCapsGetAccel(qemuCaps, virtType);
for (i = 0; i < accel->nmachineTypes; i++) {
if (STREQ_NULLABLE(accel->machineTypes[i].name, name))
return accel->machineTypes[i].hotplugCpus;
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
}
return false;
}
qemu: Introduce virQEMUCapsGetMachineDefaultCPU Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-26 13:22:38 +00:00
const char *
virQEMUCapsGetMachineDefaultCPU(virQEMUCapsPtr qemuCaps,
const char *name,
virDomainVirtType type)
{
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, type);
qemuMonitorCPUDefsPtr defs = accel->cpuModels;
const char *cpuType = NULL;
size_t i;
if (!name || !defs)
return NULL;
for (i = 0; i < accel->nmachineTypes; i++) {
if (STREQ(accel->machineTypes[i].name, name)) {
cpuType = accel->machineTypes[i].defaultCPU;
break;
}
}
if (!cpuType)
return NULL;
for (i = 0; i < defs->ncpus; i++) {
if (STREQ_NULLABLE(defs->cpus[i].type, cpuType))
return defs->cpus[i].name;
}
return NULL;
}
qemu: taint the VM if it is using a deprecated CPU model Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 11:48:23 +00:00
bool
virQEMUCapsIsCPUDeprecated(virQEMUCapsPtr qemuCaps,
virDomainVirtType type,
const char *model)
{
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, type);
qemuMonitorCPUDefsPtr defs = accel->cpuModels;
size_t i;
for (i = 0; i < defs->ncpus; i++) {
if (STREQ_NULLABLE(defs->cpus[i].name, model))
return defs->cpus[i].deprecated;
}
return false;
}
qemu: taint the VM if it is using a deprecated machine type Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 11:48:23 +00:00
bool
virQEMUCapsIsMachineDeprecated(virQEMUCapsPtr qemuCaps,
virDomainVirtType type,
const char *machine)
{
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, type);
size_t i;
for (i = 0; i < accel->nmachineTypes; i++) {
if (STREQ_NULLABLE(accel->machineTypes[i].name, machine))
return accel->machineTypes[i].deprecated;
}
return false;
}
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
bool
virQEMUCapsGetMachineNumaMemSupported(virQEMUCapsPtr qemuCaps,
virDomainVirtType virtType,
const char *name)
{
virQEMUCapsAccelPtr accel;
size_t i;
accel = virQEMUCapsGetAccel(qemuCaps, virtType);
for (i = 0; i < accel->nmachineTypes; i++) {
if (STREQ(accel->machineTypes[i].name, name))
return accel->machineTypes[i].numaMemSupported;
}
return false;
}
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
const char *
virQEMUCapsGetMachineDefaultRAMid(virQEMUCapsPtr qemuCaps,
virDomainVirtType virtType,
const char *name)
{
virQEMUCapsAccelPtr accel;
size_t i;
accel = virQEMUCapsGetAccel(qemuCaps, virtType);
for (i = 0; i < accel->nmachineTypes; i++) {
if (STREQ(accel->machineTypes[i].name, name))
return accel->machineTypes[i].defaultRAMid;
}
return NULL;
}
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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsCommands),
qemu: Make probing for commands declarative
2013-06-19 08:00:10 +00:00
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) &&
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;
qemu: caps: Probe events from 'query-qmp-schema' rather than 'query-events' QEMU plans to deprecate 'query-events' as it's non-extensible. Events are also described by 'query-qmp-schema' so we can use that one instead. This patch adds detection of events to virQEMUCapsProbeQMPSchemaCapabilities using the same structure declaring them for the old approach (virQEMUCapsEvents). This is possible as the name is the same in the QMP schema and our detector supports that trivially. For any complex queries virQEMUCapsQMPSchemaQueries can be used in the future. For now we still call 'query-events' and discard the result so that it's obvious that the tests pass. This will be cleaned up later. https://bugzilla.redhat.com/show_bug.cgi?id=1673320 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-02-07 11:50:27 +00:00
/* we can probe events also from the QMP schema so we can skip this here */
qemu: caps: Don't call 'query-events' when we probe events from QMP schema Avoid calling the command and fix test fallout. https://bugzilla.redhat.com/show_bug.cgi?id=1673320 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-02-07 12:03:37 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_QMP_SCHEMA))
qemu: caps: Probe events from 'query-qmp-schema' rather than 'query-events' QEMU plans to deprecate 'query-events' as it's non-extensible. Events are also described by 'query-qmp-schema' so we can use that one instead. This patch adds detection of events to virQEMUCapsProbeQMPSchemaCapabilities using the same structure declaring them for the old approach (virQEMUCapsEvents). This is possible as the name is the same in the QMP schema and our detector supports that trivially. For any complex queries virQEMUCapsQMPSchemaQueries can be used in the future. For now we still call 'query-events' and discard the result so that it's obvious that the tests pass. This will be cleaned up later. https://bugzilla.redhat.com/show_bug.cgi?id=1673320 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-02-07 11:50:27 +00:00
return 0;
qemu: caps: Don't call 'query-events' when we probe events from QMP schema Avoid calling the command and fix test fallout. https://bugzilla.redhat.com/show_bug.cgi?id=1673320 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-02-07 12:03:37 +00:00
if ((nevents = qemuMonitorGetEvents(mon, &events)) < 0)
return -1;
qemu: caps: Probe events from 'query-qmp-schema' rather than 'query-events' QEMU plans to deprecate 'query-events' as it's non-extensible. Events are also described by 'query-qmp-schema' so we can use that one instead. This patch adds detection of events to virQEMUCapsProbeQMPSchemaCapabilities using the same structure declaring them for the old approach (virQEMUCapsEvents). This is possible as the name is the same in the QMP schema and our detector supports that trivially. For any complex queries virQEMUCapsQMPSchemaQueries can be used in the future. For now we still call 'query-events' and discard the result so that it's obvious that the tests pass. This will be cleaned up later. https://bugzilla.redhat.com/show_bug.cgi?id=1673320 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-02-07 11:50:27 +00:00
qemu: Make probing for events declarative
2013-06-19 07:24:54 +00:00
virQEMUCapsProcessStringFlags(qemuCaps,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsEvents),
qemu: Make probing for events declarative
2013-06-19 07:24:54 +00:00
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;
}
virQEMUCapsProbeQMPDevices: Split up into logical chunks The function was parsing 'qom-list-types' and then also calling function which parses 'device-list-properties' and also 'qom-list-properties'. Split it up into individual functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 14:53:31 +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
virQEMUCapsProbeQMPDevices: Split up into logical chunks The function was parsing 'qom-list-types' and then also calling function which parses 'device-list-properties' and also 'qom-list-properties'. Split it up into individual functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 14:53:31 +00:00
virQEMUCapsProbeQMPObjectTypes(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
{
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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsObjectTypes),
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
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
virQEMUCapsProbeQMPDevices: Split up into logical chunks The function was parsing 'qom-list-types' and then also calling function which parses 'device-list-properties' and also 'qom-list-properties'. Split it up into individual functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 14:53:31 +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
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
virQEMUCapsProbeQMPDevices: Split up into logical chunks The function was parsing 'qom-list-types' and then also calling function which parses 'device-list-properties' and also 'qom-list-properties'. Split it up into individual functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 14:53:31 +00:00
static int
virQEMUCapsProbeQMPDeviceProperties(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
virQEMUCapsProbeQMPDeviceProperties: Switch to local implementation Reimplement device property detection directly rather than using virQEMUCapsProbeQMPGenericProps in preparation for changes to the detection code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 15:12:12 +00:00
size_t i;
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsDeviceProps); i++) {
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
virQEMUCapsDeviceTypeProps *device = virQEMUCapsDeviceProps + i;
util: hash: Retire 'virHashTable' in favor of 'GHashTable' Don't hide our use of GHashTable behind our typedef. This will also promote the use of glibs hash function directly. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Matt Coleman <matt@datto.com>
2020-10-22 17:04:18 +00:00
g_autoptr(GHashTable) qemuprops = NULL;
qemuMonitorGetDeviceProps: Return data in a hash table Create a hash table of device property names which also stores the corresponding JSON object so that the detection code can look at the recently added 'default-value' field and possibly others. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 17:53:43 +00:00
size_t j;
virQEMUCapsProbeQMPDeviceProperties: Switch to local implementation Reimplement device property detection directly rather than using virQEMUCapsProbeQMPGenericProps in preparation for changes to the detection code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 15:12:12 +00:00
if (device->capsCondition >= 0 &&
!virQEMUCapsGet(qemuCaps, device->capsCondition))
continue;
qemuMonitorGetDeviceProps: Return data in a hash table Create a hash table of device property names which also stores the corresponding JSON object so that the detection code can look at the recently added 'default-value' field and possibly others. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 17:53:43 +00:00
if (!(qemuprops = qemuMonitorGetDeviceProps(mon, device->type)))
virQEMUCapsProbeQMPDeviceProperties: Switch to local implementation Reimplement device property detection directly rather than using virQEMUCapsProbeQMPGenericProps in preparation for changes to the detection code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 15:12:12 +00:00
return -1;
qemuMonitorGetDeviceProps: Return data in a hash table Create a hash table of device property names which also stores the corresponding JSON object so that the detection code can look at the recently added 'default-value' field and possibly others. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 17:53:43 +00:00
for (j = 0; j < device->nprops; j++) {
virJSONValuePtr entry = virHashLookup(qemuprops, device->props[j].value);
if (!entry)
continue;
virQEMUCapsSet(qemuCaps, device->props[j].flag);
virQEMUCapsProbeQMPDeviceProperties: Add per-property callbacks QEMU-5.0 added 'default-value' field for any applicable property returned by 'device-list-properties'. Add an optional callback for any device property definition which will allow detection of features and default values based on this new data. This unfortunately means that the description of properties had to move from the slightly-too-generic 'struct virQEMUCapsStringFlags' to a new type (virQEMUCapsDevicePropsFlags) which also has the callback property and the corresponding change in the initializers. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 19:29:55 +00:00
if (device->props[j].cb &&
device->props[j].cb(entry, qemuCaps) < 0)
return -1;
qemuMonitorGetDeviceProps: Return data in a hash table Create a hash table of device property names which also stores the corresponding JSON object so that the detection code can look at the recently added 'default-value' field and possibly others. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 17:53:43 +00:00
}
virQEMUCapsProbeQMPDeviceProperties: Switch to local implementation Reimplement device property detection directly rather than using virQEMUCapsProbeQMPGenericProps in preparation for changes to the detection code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 15:12:12 +00:00
}
return 0;
virQEMUCapsProbeQMPDevices: Split up into logical chunks The function was parsing 'qom-list-types' and then also calling function which parses 'device-list-properties' and also 'qom-list-properties'. Split it up into individual functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 14:53:31 +00:00
}
static int
virQEMUCapsProbeQMPObjectProperties(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
virQEMUCapsProbeQMPObjectTypes: Fold in virQEMUCapsProbeQMPGenericProps virQEMUCapsProbeQMPGenericProps is used only in one place now. Move the code directly to virQEMUCapsProbeQMPObjectTypes. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 15:15:14 +00:00
size_t i;
virQEMUCapsProbeQMPDevices: Split up into logical chunks The function was parsing 'qom-list-types' and then also calling function which parses 'device-list-properties' and also 'qom-list-properties'. Split it up into individual functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 14:53:31 +00:00
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QOM_LIST_PROPERTIES))
return 0;
virQEMUCapsProbeQMPObjectTypes: Fold in virQEMUCapsProbeQMPGenericProps virQEMUCapsProbeQMPGenericProps is used only in one place now. Move the code directly to virQEMUCapsProbeQMPObjectTypes. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 15:15:14 +00:00
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsObjectProps); i++) {
virQEMUCapsObjectTypeProps *props = virQEMUCapsObjectProps + i;
lib: Replace VIR_AUTOSTRINGLIST with GStrv Glib provides g_auto(GStrv) which is in-place replacement of our VIR_AUTOSTRINGLIST. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-12-01 08:21:32 +00:00
g_auto(GStrv) values = NULL;
virQEMUCapsProbeQMPObjectTypes: Fold in virQEMUCapsProbeQMPGenericProps virQEMUCapsProbeQMPGenericProps is used only in one place now. Move the code directly to virQEMUCapsProbeQMPObjectTypes. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 15:15:14 +00:00
int nvalues;
if (props->capsCondition >= 0 &&
!virQEMUCapsGet(qemuCaps, props->capsCondition))
continue;
if ((nvalues = qemuMonitorGetObjectProps(mon, props->type, &values)) < 0)
return -1;
virQEMUCapsProcessStringFlags(qemuCaps,
props->nprops,
props->props,
nvalues, values);
}
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
}
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 */
Add armv6l Support as guest Support for armv6l qemu guests has been added. Tested with arm1176 CPU on x86. Signed-off-by: Stefan Schallenberg <infos@nafets.de> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2018-11-28 21:45:14 +00:00
"integratorcp", /* VIR_ARCH_ARMV6L */
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
"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
};
src: replace verify(expr) with G_STATIC_ASSERT(expr) G_STATIC_ASSERT() is a drop-in functional equivalent of the GNULIB verify() macro. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-09 10:39:55 +00:00
G_STATIC_ASSERT(G_N_ELEMENTS(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
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
void
virQEMUCapsAddMachine(virQEMUCapsPtr qemuCaps,
virDomainVirtType virtType,
const char *name,
const char *alias,
const char *defaultCPU,
int maxCpus,
bool hotplugCpus,
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
bool isDefault,
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
bool numaMemSupported,
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
const char *defaultRAMid,
bool deprecated)
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
{
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, virtType);
virQEMUCapsMachineTypePtr mach;
accel->machineTypes = g_renew(virQEMUCapsMachineType,
accel->machineTypes,
++accel->nmachineTypes);
mach = &(accel->machineTypes[accel->nmachineTypes - 1]);
mach->alias = g_strdup(alias);
mach->name = g_strdup(name);
mach->defaultCPU = g_strdup(defaultCPU);
mach->maxCpus = maxCpus;
mach->hotplugCpus = hotplugCpus;
mach->qemuDefault = isDefault;
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
mach->numaMemSupported = numaMemSupported;
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
mach->defaultRAMid = g_strdup(defaultRAMid);
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
mach->deprecated = deprecated;
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
}
qemu: capabilities: Add accessor to qemu caps machine types presence Test code will need to know whether the virQEMUCaps object contains any machine types already. Add a helper and expose it via 'qemu_capspriv.h'. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:21:47 +00:00
/**
* virQEMUCapsHasMachines:
* @qemuCaps: qemu capabilities object
*
* Returns true if @qemuCaps has at least one machine type defined. This is
* called by the test suite to figure out whether to populate fake machine types
* into the list.
*/
bool
virQEMUCapsHasMachines(virQEMUCapsPtr qemuCaps)
{
return !!qemuCaps->kvm.nmachineTypes || !!qemuCaps->tcg.nmachineTypes;
}
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,
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
virDomainVirtType virtType,
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
{
qemuMonitorMachineInfoPtr *machines = NULL;
int nmachines = 0;
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];
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, virtType);
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
src/qemu: Remove the whitespace before ';'
2013-05-21 07:21:20 +00:00
for (i = 0; i < nmachines; i++) {
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
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
virQEMUCapsAddMachine(qemuCaps,
virtType,
machines[i]->name,
machines[i]->alias,
machines[i]->defaultCPU,
machines[i]->maxCpus,
machines[i]->hotplugCpus,
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
machines[i]->isDefault,
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
machines[i]->numaMemSupported,
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
machines[i]->defaultRAMid,
machines[i]->deprecated);
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 &&
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
(STREQ_NULLABLE(machines[i]->alias, preferredMachine) ||
STREQ(machines[i]->name, preferredMachine))) {
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
preferredIdx = accel->nmachineTypes - 1;
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: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
if (machines[i]->isDefault)
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
defIdx = accel->nmachineTypes - 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: 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)
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsSetDefaultMachine(accel, 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
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);
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +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
}
qemu: domain: Validate that machine type is supported by qemu Every supported qemu is able to return the list of machine types it supports so we can start validating it against that list. The advantage is a better error message, and the change will also prevent having stale test data. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-22 09:06:53 +00:00
bool
qemu: Make virQEMUCapsIsMachineSupported static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:51:50 +00:00
virQEMUCapsIsMachineSupported(virQEMUCapsPtr qemuCaps,
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virDomainVirtType virtType,
qemu: Make virQEMUCapsIsMachineSupported static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:51:50 +00:00
const char *canonical_machine)
{
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, virtType);
qemu: Make virQEMUCapsIsMachineSupported static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:51:50 +00:00
size_t i;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
for (i = 0; i < accel->nmachineTypes; i++) {
if (STREQ(canonical_machine, accel->machineTypes[i].name))
qemu: Make virQEMUCapsIsMachineSupported static Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 15:51:50 +00:00
return true;
}
return false;
}
qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:45:08 +00:00
static int
virQEMUCapsProbeQMPMachineProps(virQEMUCapsPtr qemuCaps,
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
virDomainVirtType virtType,
qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:45:08 +00:00
qemuMonitorPtr mon)
{
char **values;
int nvalues;
size_t i;
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QOM_LIST_PROPERTIES))
return 0;
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsMachineProps); i++) {
qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:45:08 +00:00
virQEMUCapsObjectTypeProps props = virQEMUCapsMachineProps[i];
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
const char *canon = virQEMUCapsGetCanonicalMachine(qemuCaps, virtType, props.type);
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *type = NULL;
qemu: Add -machine suffix automatically The QOM type for machine types is the machine type name followed by the -machine suffix. Since this is always the case, we can make virQEMUCapsMachineProps more readable and avoid repetition by not including the suffix there and adding it automatically while processing the data; moreover, when later on we will start figuring out which specific versioned machine type to probe at runtime instead of doing so statically, adding the suffix dynamically will become necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 08:18:58 +00:00
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
if (!virQEMUCapsIsMachineSupported(qemuCaps, virtType, canon))
qemu: Only probe available machine types Since we know the full list of machine types supported by the QEMU binary when probing machine type properties, we can save some work (and eventually test suite churn, as more architecture-specific machine types need to be probed) by only probing machines that we know exist. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 10:04:48 +00:00
continue;
qemu: Add -machine suffix automatically The QOM type for machine types is the machine type name followed by the -machine suffix. Since this is always the case, we can make virQEMUCapsMachineProps more readable and avoid repetition by not including the suffix there and adding it automatically while processing the data; moreover, when later on we will start figuring out which specific versioned machine type to probe at runtime instead of doing so statically, adding the suffix dynamically will become necessary. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 08:18:58 +00:00
/* The QOM type for machine types is the machine type name
* followed by the -machine suffix */
qemu: Use g_strdup_printf() instead of virAsprintf() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-10-22 13:26:14 +00:00
type = g_strdup_printf("%s-machine", canon);
qemu: Introduce virQEMUCapsProbeQMPMachineProps() Up until now we've probed machine type properties, along with properties for other types, in virQEMUCapsProbeQMPDevices(), but soon we're going to need some logic that is specific to machine types and as such wouldn't quite fit into that function. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:45:08 +00:00
if ((nvalues = qemuMonitorGetObjectProps(mon, type, &values)) < 0)
return -1;
virQEMUCapsProcessStringFlags(qemuCaps,
props.nprops,
props.props,
nvalues, values);
virStringListFreeCount(values, nvalues);
}
return 0;
}
qemu: Split virQEMUCapsFetchCPUModels Most of the code moved to a new virQEMUCapsFetchCPUDefinitions function and the existing virQEMUCapsFetchCPUModels just becomes a small wrapper around virQEMUCapsFetchCPUDefinitions and virQEMUCapsCPUDefsToModels. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-09 08:16:17 +00:00
static int
virQEMUCapsFetchCPUDefinitions(qemuMonitorPtr mon,
virArch arch,
qemuMonitorCPUDefsPtr *cpuDefs)
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: Introduce qemuMonitorCPUDefs struct It is a container for a CPU models list (qemuMonitorCPUDefInfo) and a number of elements in this list. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 11:42:00 +00:00
g_autoptr(qemuMonitorCPUDefs) defs = NULL;
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: Change return type of virQEMUCapsFetchCPUDefinitions The function would return a valid virDomainCapsCPUModelsPtr with empty CPU models list if query-cpu-definitions exists in QEMU, but returns GenericError meaning it's not in fact implemented. This behaviour is a bit strange especially after such virDomainCapsCPUModels structure is stored in capabilities XML and parsed back, which will result in NULL virDomainCapsCPUModelsPtr rather than a structure containing nothing. Let's just keep virDomainCapsCPUModelsPtr NULL if the QMP command is not implemented and change the return value to int so that callers can easily check for failure or success. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-10 14:44:40 +00:00
qemu: Split virQEMUCapsFetchCPUModels Most of the code moved to a new virQEMUCapsFetchCPUDefinitions function and the existing virQEMUCapsFetchCPUModels just becomes a small wrapper around virQEMUCapsFetchCPUDefinitions and virQEMUCapsCPUDefsToModels. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-09 08:16:17 +00:00
*cpuDefs = 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: Introduce qemuMonitorCPUDefs struct It is a container for a CPU models list (qemuMonitorCPUDefInfo) and a number of elements in this list. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 11:42:00 +00:00
if (qemuMonitorGetCPUDefinitions(mon, &defs) < 0)
qemu: Change return type of virQEMUCapsFetchCPUDefinitions The function would return a valid virDomainCapsCPUModelsPtr with empty CPU models list if query-cpu-definitions exists in QEMU, but returns GenericError meaning it's not in fact implemented. This behaviour is a bit strange especially after such virDomainCapsCPUModels structure is stored in capabilities XML and parsed back, which will result in NULL virDomainCapsCPUModelsPtr rather than a structure containing nothing. Let's just keep virDomainCapsCPUModelsPtr NULL if the QMP command is not implemented and change the return value to int so that callers can easily check for failure or success. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-10 14:44:40 +00:00
return -1;
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +00:00
if (!defs)
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
qemu: Adapt to changed ppc64 CPU model names QEMU 2.11 for ppc64 changed all CPU model names to lower case. Since libvirt can't change the model names for compatibility reasons, we need to translate the matching lower case models to the names known by libvirt. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-17 15:08:42 +00:00
/* QEMU 2.11 for Power renamed all CPU models to lower case, we need to
* translate them back to libvirt's upper case model names. */
qemu: fix CPU model error probing capabilities for ppc The CPU driver only supports CPU models for PPC64 architecture, not plain PPC. Failed to probe capabilities for /usr/bin/qemu-system-ppc: this function is not supported by the connection driver: 'ppc' architecture is not supported by CPU driver This fixes a bug in commit db873ab3bc5f6fbd7d227727a62ccfee3d1c3e9d Author: Jiri Denemark <jdenemar@redhat.com> Date: Thu May 17 17:08:42 2018 +0200 qemu: Adapt to changed ppc64 CPU model names Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-18 18:20:43 +00:00
if (ARCH_IS_PPC64(arch)) {
lib: Replace VIR_AUTOSTRINGLIST with GStrv Glib provides g_auto(GStrv) which is in-place replacement of our VIR_AUTOSTRINGLIST. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-12-01 08:21:32 +00:00
g_auto(GStrv) libvirtModels = NULL;
qemu: Adapt to changed ppc64 CPU model names QEMU 2.11 for ppc64 changed all CPU model names to lower case. Since libvirt can't change the model names for compatibility reasons, we need to translate the matching lower case models to the names known by libvirt. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-17 15:08:42 +00:00
char **name;
if (virCPUGetModels(arch, &libvirtModels) < 0)
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +00:00
return -1;
qemu: Adapt to changed ppc64 CPU model names QEMU 2.11 for ppc64 changed all CPU model names to lower case. Since libvirt can't change the model names for compatibility reasons, we need to translate the matching lower case models to the names known by libvirt. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-17 15:08:42 +00:00
for (name = libvirtModels; name && *name; name++) {
qemu: Introduce qemuMonitorCPUDefs struct It is a container for a CPU models list (qemuMonitorCPUDefInfo) and a number of elements in this list. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 11:42:00 +00:00
for (i = 0; i < defs->ncpus; i++) {
qemu: Flatten qemuMonitorCPUDefs.cpus Let's store qemuMonitorCPUDefInfo directly in the array of CPUs in qemuMonitorCPUDefs rather then using an array of pointers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 11:45:37 +00:00
if (STRCASENEQ(defs->cpus[i].name, *name))
qemu: Adapt to changed ppc64 CPU model names QEMU 2.11 for ppc64 changed all CPU model names to lower case. Since libvirt can't change the model names for compatibility reasons, we need to translate the matching lower case models to the names known by libvirt. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-17 15:08:42 +00:00
continue;
qemu: Flatten qemuMonitorCPUDefs.cpus Let's store qemuMonitorCPUDefInfo directly in the array of CPUs in qemuMonitorCPUDefs rather then using an array of pointers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 11:45:37 +00:00
VIR_FREE(defs->cpus[i].name);
defs->cpus[i].name = g_strdup(*name);
qemu: Adapt to changed ppc64 CPU model names QEMU 2.11 for ppc64 changed all CPU model names to lower case. Since libvirt can't change the model names for compatibility reasons, we need to translate the matching lower case models to the names known by libvirt. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-17 15:08:42 +00:00
}
}
}
qemu: Split virQEMUCapsFetchCPUModels Most of the code moved to a new virQEMUCapsFetchCPUDefinitions function and the existing virQEMUCapsFetchCPUModels just becomes a small wrapper around virQEMUCapsFetchCPUDefinitions and virQEMUCapsCPUDefsToModels. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-09 08:16:17 +00:00
*cpuDefs = g_steal_pointer(&defs);
return 0;
}
int
virQEMUCapsFetchCPUModels(qemuMonitorPtr mon,
virArch arch,
virDomainCapsCPUModelsPtr *cpuModels)
{
g_autoptr(qemuMonitorCPUDefs) defs = NULL;
*cpuModels = NULL;
if (virQEMUCapsFetchCPUDefinitions(mon, arch, &defs) < 0)
return -1;
if (defs && !(*cpuModels = virQEMUCapsCPUDefsToModels(defs, NULL, NULL)))
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +00:00
return -1;
qemu: Change return type of virQEMUCapsFetchCPUDefinitions The function would return a valid virDomainCapsCPUModelsPtr with empty CPU models list if query-cpu-definitions exists in QEMU, but returns GenericError meaning it's not in fact implemented. This behaviour is a bit strange especially after such virDomainCapsCPUModels structure is stored in capabilities XML and parsed back, which will result in NULL virDomainCapsCPUModelsPtr rather than a structure containing nothing. Let's just keep virDomainCapsCPUModelsPtr NULL if the QMP command is not implemented and change the return value to int so that callers can easily check for failure or success. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-10 14:44:40 +00:00
qemu: Introduce virQEMUCapsCPUDefsToModels The function translates qemuMonitorCPUDefsPtr (used by QEMU caps probing code) into virDomainCapsCPUModelsPtr used by domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 13:59:34 +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
}
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
qemu: Introduce virQEMUCapsProbeCPUDefinitionsTest It is a tiny wrapper around virQEMUCapsProbeQMPCPUDefinitions which will soon get private parameters and thus it cannot be exposed outside qemu_capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 12:08:16 +00:00
static int
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
virQEMUCapsProbeQMPCPUDefinitions(virQEMUCapsPtr qemuCaps,
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
virQEMUCapsAccelPtr accel,
qemuMonitorPtr mon)
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
{
qemu: probe for "-cpu max" support This is a special CPU model similar to "-cpu host", so won't use our normal CPU model detection logic. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-05 18:21:14 +00:00
qemuMonitorCPUDefsPtr defs;
size_t i;
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
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_DEFINITIONS))
return 0;
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
if (virQEMUCapsFetchCPUDefinitions(mon, qemuCaps->arch, &accel->cpuModels) < 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
return -1;
qemu: probe for "-cpu max" support This is a special CPU model similar to "-cpu host", so won't use our normal CPU model detection logic. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-05 18:21:14 +00:00
defs = accel->cpuModels;
for (i = 0; i < defs->ncpus; i++) {
if (STREQ_NULLABLE(defs->cpus[i].name, "max")) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_CPU_MAX);
break;
}
}
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 0;
}
qemu: Introduce virQEMUCapsProbeCPUDefinitionsTest It is a tiny wrapper around virQEMUCapsProbeQMPCPUDefinitions which will soon get private parameters and thus it cannot be exposed outside qemu_capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 12:08:16 +00:00
int
virQEMUCapsProbeCPUDefinitionsTest(virQEMUCapsPtr qemuCaps,
qemuMonitorPtr mon)
{
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
return virQEMUCapsProbeQMPCPUDefinitions(qemuCaps, &qemuCaps->kvm, mon);
qemu: Introduce virQEMUCapsProbeCPUDefinitionsTest It is a tiny wrapper around virQEMUCapsProbeQMPCPUDefinitions which will soon get private parameters and thus it cannot be exposed outside qemu_capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 12:08:16 +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
virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
virQEMUCapsAccelPtr accel,
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,
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
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
{
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
const char *model = virtType == VIR_DOMAIN_VIRT_KVM ? "host" : "max";
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;
util: hash: Retire 'virHashTable' in favor of 'GHashTable' Don't hide our use of GHashTable behind our typedef. This will also promote the use of glibs hash function directly. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Matt Coleman <matt@datto.com>
2020-10-22 17:04:18 +00:00
GHashTable *hash = NULL;
qemu_monitor: use cpu def instead of char for expansion When expanding a CPU model via query-cpu-model-expansion, any features that were a part of the original model are discarded. For exmaple, when expanding modelA with features f1, f2, a full expansion may reveal feature f3, but the expanded model will not include f1 or f2. Let's pass a virCPUDefPtr to the expansion function in preparation for taking features into consideration. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-4-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:24:54 +00:00
virCPUDefPtr cpu;
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_monitor: allow cpu props to be optional Some older s390 CPU models (e.g. z900) will not report props as a response from query-cpu-model-expansion. As such, we should make the props field optional when parsing the return data from the QMP response. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-6-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:24:56 +00:00
bool fail_no_props = 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
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;
conf: make virCPUDef into a ref counted struct Annoyingly there was no existing constructor, and identifying all the places which do a VIR_ALLOC(cpu) is a bit error prone. Hopefully this has found & converted them all. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-29 11:00:26 +00:00
cpu = virCPUDefNew();
qemu_monitor: use cpu def instead of char for expansion When expanding a CPU model via query-cpu-model-expansion, any features that were a part of the original model are discarded. For exmaple, when expanding modelA with features f1, f2, a full expansion may reveal feature f3, but the expanded model will not include f1 or f2. Let's pass a virCPUDefPtr to the expansion function in preparation for taking features into consideration. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-4-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:24:54 +00:00
qemu: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
cpu->model = g_strdup(model);
qemu: Remove references to "cpu_map.xml" in the code "cpu_map.xml" was moved to a directory "cpu_map" and split up into several files. Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2020-10-09 10:47:18 +00:00
/* Some x86_64 features defined in src/cpu_map/ use spelling which differ
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
* from the one preferred by QEMU. Static expansion would give us only the
qemu: Don't use full CPU model expansion We used type=full expansion on the result of previous type=static expansion to get all possible spellings of CPU features. Since we can now translate the QEMU's canonical names to our names, we can drop this magic and do only type=static CPU model expansion. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-12 11:54:27 +00:00
* preferred spelling. With new QEMU we always use the QEMU's canonical
* names of all features and translate between them and our names. But for
* older version of QEMU we need to do a full expansion on the result of
* the initial static expansion to get all variants of feature names.
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
*/
qemu: Don't use full CPU model expansion We used type=full expansion on the result of previous type=static expansion to get all possible spellings of CPU features. Since we can now translate the QEMU's canonical names to our names, we can drop this magic and do only type=static CPU model expansion. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-12 11:54:27 +00:00
if (ARCH_IS_X86(qemuCaps->arch) &&
qemu: Perform full expansion on ARM The ARM implementation of query-cpu-model-expansion only supports full expansion, so we have to make sure we're using that expansion mode if we want to obtain any useful data. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-06-24 12:16:17 +00:00
!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CANONICAL_CPU_FEATURES)) {
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
type = QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC_FULL;
qemu: Perform full expansion on ARM The ARM implementation of query-cpu-model-expansion only supports full expansion, so we have to make sure we're using that expansion mode if we want to obtain any useful data. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-06-24 12:16:17 +00:00
} else if (ARCH_IS_ARM(qemuCaps->arch)) {
type = QEMU_MONITOR_CPU_MODEL_EXPANSION_FULL;
} else {
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
type = QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC;
qemu: Perform full expansion on ARM The ARM implementation of query-cpu-model-expansion only supports full expansion, so we have to make sure we're using that expansion mode if we want to obtain any useful data. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Tested-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-06-24 12:16:17 +00:00
}
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
qemu_monitor: allow cpu props to be optional Some older s390 CPU models (e.g. z900) will not report props as a response from query-cpu-model-expansion. As such, we should make the props field optional when parsing the return data from the QMP response. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-6-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:24:56 +00:00
/* Older s390 models do not report a feature set */
if (ARCH_IS_S390(qemuCaps->arch))
fail_no_props = false;
if (qemuMonitorGetCPUModelExpansion(mon, type, cpu, true, fail_no_props,
&modelInfo) < 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
/* 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: Avoid probing unsupported migratable CPU expansion Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-02 23:07:06 +00:00
virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION_MIGRATABLE) &&
qemu_monitor: allow cpu props to be optional Some older s390 CPU models (e.g. z900) will not report props as a response from query-cpu-model-expansion. As such, we should make the props field optional when parsing the return data from the QMP response. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-6-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:24:56 +00:00
qemuMonitorGetCPUModelExpansion(mon, type, cpu, false, fail_no_props,
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
&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;
Replace all instances of 'virHashCreate' with 'virHashNew' It doesn't make much sense to configure the bucket count in the hash table for each case specifically. Replace all calls of virHashCreate with virHashNew which has a pre-set size and remove virHashCreate completely. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2020-10-20 16:43:20 +00:00
if (!(hash = virHashNew(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: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
accel->hostCPU.info = g_steal_pointer(&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_monitor: use cpu def instead of char for expansion When expanding a CPU model via query-cpu-model-expansion, any features that were a part of the original model are discarded. For exmaple, when expanding modelA with features f1, f2, a full expansion may reveal feature f3, but the expanded model will not include f1 or f2. Let's pass a virCPUDefPtr to the expansion function in preparation for taking features into consideration. Signed-off-by: Collin Walling <walling@linux.ibm.com> Message-Id: <1568924706-2311-4-git-send-email-walling@linux.ibm.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-19 20:24:54 +00:00
virCPUDefFree(cpu);
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)
{
qemu_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
qemuMonitorCPUModelInfoPtr modelInfo;
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
char **list;
size_t i;
size_t n;
int ret = -1;
*features = NULL;
qemu_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
modelInfo = virQEMUCapsGetCPUModelInfo(qemuCaps, virtType);
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
qemu_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
if (!modelInfo)
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
return 0;
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
list = g_new0(char *, modelInfo->nprops + 1);
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
n = 0;
qemu_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
for (i = 0; i < modelInfo->nprops; i++) {
qemuMonitorCPUPropertyPtr prop = modelInfo->props + i;
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
if (migratable && prop->migratable == VIR_TRISTATE_BOOL_NO)
continue;
qemu: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
list[n++] = g_strdup(virQEMUCapsCPUFeatureFromQEMU(qemuCaps, prop->name));
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
}
qemu: use g_steal_pointer instead of VIR_STEAL_PTR Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-16 11:43:18 +00:00
*features = g_steal_pointer(&list);
qemu_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
if (migratable && !modelInfo->migratability)
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
ret = 1;
else
ret = 0;
Use g_strfeev instead of virStringFreeList Both accept a NULL value gracefully and virStringFreeList does not zero the pointer afterwards, so a straight replace is safe. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2020-08-02 17:36:03 +00:00
g_strfreev(list);
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
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,
},
qemu: Extend QEMU capabilities with 'tpm-spapr' Extend the QEMU capabilties with tpm-spapr support. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-02-05 18:35:47 +00:00
{
.type = VIR_DOMAIN_TPM_MODEL_SPAPR,
.caps = QEMU_CAPS_DEVICE_TPM_SPAPR,
},
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) {
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsTPMModelsToCaps); 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
const char *needle = virDomainTPMModelTypeToString(
virQEMUCapsTPMModelsToCaps[i].type);
Replace virStringListHasString by g_strv_contains The glib variant doesn't accept NULL list, but there's just one caller where it wasn't checked explicitly, thus there's no need for our own wrapper. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 17:39:47 +00:00
if (g_strv_contains((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);
}
}
Use g_strfeev instead of virStringFreeList Both accept a NULL value gracefully and virStringFreeList does not zero the pointer afterwards, so a straight replace is safe. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2020-08-02 17:36:03 +00:00
g_strfreev(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) {
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsTPMTypesToCaps); 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
const char *needle = virDomainTPMBackendTypeToString(
virQEMUCapsTPMTypesToCaps[i].type);
Replace virStringListHasString by g_strv_contains The glib variant doesn't accept NULL list, but there's just one caller where it wasn't checked explicitly, thus there's no need for our own wrapper. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-03 17:39:47 +00:00
if (g_strv_contains((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);
}
}
Use g_strfeev instead of virStringFreeList Both accept a NULL value gracefully and virStringFreeList does not zero the pointer afterwards, so a straight replace is safe. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2020-08-02 17:36:03 +00:00
g_strfreev(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: 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_capabilities: Introduce QEMU_CAPS_OVERCOMMIT Added in QEMU commit of v3.0.0-rc0~48^2~9 (then fixed by v3.1.0-rc0~119^2~37) QEMU is replacing '-realtime mlock' with '-overcommit mem-lock'. Add a capability to tell if we're dealing new new enough qemu to use the replacement. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 08:16:06 +00:00
{ "overcommit", NULL, QEMU_CAPS_OVERCOMMIT },
qemu: add support for specifying CPU "dies" topology parameter QEMU since 4.1.0 supports the "dies" parameter for -smp Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-16 15:28:09 +00:00
{ "smp-opts", "dies", QEMU_CAPS_SMP_DIES },
qemu: capabilities: add QEMU_CAPS_FSDEV_MULTIDEVS The QEMU 9pfs 'multidevs' option exists since QEMU 4.2. Probe QEMU's command line set though to check whether this option is really available, and if yes enable this new QEMU_CAPS_FSDEV_MULTIDEVS capability on libvirt side. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-03-30 18:04:47 +00:00
{ "fsdev", "multidevs", QEMU_CAPS_FSDEV_MULTIDEVS },
qemu: Introduce fw_cfg capability This capability tracks whether QEMU supports -fw_cfg command line option, more specifically whether it allows specifying filename. There are some releases of QEMU which support -fw_cfg but not filename. If this is ever a problem we can refine the capability later on. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-02 14:57:56 +00:00
{ "fw_cfg", "file", QEMU_CAPS_FW_CFG },
qemu: capabilities: add QEMU_CAPS_FSDEV_CREATEMODE The QEMU 9pfs 'fmode' and 'dmode' options have existed since QEMU 2.10. Probe QEMU's command line set to check whether these options are available, and if yes, enable this new QEMU_CAPS_FSDEV_CREATEMODE capability on libvirt side. Signed-off-by: Brian Turek <brian.turek@gmail.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-10-08 14:32:23 +00:00
{ "fsdev", "fmode", QEMU_CAPS_FSDEV_CREATEMODE }, /* Could have also checked fsdev->dmode */
qemu: probe for -vnc supporting use of QemuOpts syntax This was introduced in QEMU 2.2.0, and is visible by -vnc appearing in the "query-command-line-options" data. Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-16 11:45:46 +00:00
{ "vnc", "display", QEMU_CAPS_VNC_OPTS },
qemu: probe for -vnc power-control option support Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-16 13:34:26 +00:00
{ "vnc", "power-control", QEMU_CAPS_VNC_POWER_CONTROL },
qemu: probe for -vnc audiodev property The -audiodev arg is a new way to configure audio devices in QEMU to replace the QEMU_AUDIO_DRV env variable. This arg is not visible in the "query-command-line-options" output since it is entirely QAPI driven, not QemuOpts. It also isn't in "query-qmp-schema" though since there's no QMP command that uses the Audiodev type yet. So probe for the existance of this feature by looking for the -vnc "audiodev" property. This won't let us determine which precise audio backends QEMU has been built with, but for now that's no worse than with env variables today. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-23 16:16:28 +00:00
{ "vnc", "audiodev", QEMU_CAPS_AUDIODEV },
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)
{
virQEMUCapsProbeQMPCommandLine: Rewrite using qemuMonitorGetCommandLineOptions Use the new handler to fetch the required data and do the extraction locally without conversion to string list. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-11-30 17:05:23 +00:00
g_autoptr(GHashTable) options = NULL;
size_t i;
if (!(options = qemuMonitorGetCommandLineOptions(mon)))
return -1;
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
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsCommandLine); i++) {
virQEMUCapsProbeQMPCommandLine: Rewrite using qemuMonitorGetCommandLineOptions Use the new handler to fetch the required data and do the extraction locally without conversion to string list. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-11-30 17:05:23 +00:00
virJSONValuePtr option = g_hash_table_lookup(options, virQEMUCapsCommandLine[i].option);
size_t 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
virQEMUCapsProbeQMPCommandLine: Rewrite using qemuMonitorGetCommandLineOptions Use the new handler to fetch the required data and do the extraction locally without conversion to string list. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-11-30 17:05:23 +00:00
if (!option)
continue;
/* not looking for a specific argument */
if (!virQEMUCapsCommandLine[i].param) {
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
virQEMUCapsSet(qemuCaps, virQEMUCapsCommandLine[i].flag);
virQEMUCapsProbeQMPCommandLine: Rewrite using qemuMonitorGetCommandLineOptions Use the new handler to fetch the required data and do the extraction locally without conversion to string list. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-11-30 17:05:23 +00:00
continue;
}
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
virQEMUCapsProbeQMPCommandLine: Rewrite using qemuMonitorGetCommandLineOptions Use the new handler to fetch the required data and do the extraction locally without conversion to string list. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-11-30 17:05:23 +00:00
for (j = 0; j < virJSONValueArraySize(option); j++) {
virJSONValuePtr param = virJSONValueArrayGet(option, j);
const char *paramname = virJSONValueObjectGetString(param, "name");
if (STREQ_NULLABLE(virQEMUCapsCommandLine[i].param, paramname))
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);
}
}
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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsMigration),
qemu: Add RDMA migration capabilities
2014-09-11 12:11:54 +00:00
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;
qemu: Decide whether check GIC caps in virQEMUCapsProbeQMPGICCapabilities Move the check out of virQEMUCapsInitQMPMonitor similarly to other functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-04-02 10:31:31 +00:00
if (!(qemuCaps->arch == VIR_ARCH_AARCH64 ||
qemuCaps->arch == VIR_ARCH_ARMV6L ||
qemuCaps->arch == VIR_ARCH_ARMV7L))
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
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: 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: Move SEV capability handling into virQEMUCapsProbeQMPSEVCapabilities Move the code out of virQEMUCapsInitQMPMonitor similarly to other functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-04-02 10:31:31 +00:00
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_SEV_GUEST))
return 0;
if ((rc = qemuMonitorGetSEVCapabilities(mon, &caps)) < 0)
return -1;
/* SEV isn't actually supported */
if (rc == 0) {
virQEMUCapsClear(qemuCaps, QEMU_CAPS_SEV_GUEST);
return 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
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: Move SEV capability handling into virQEMUCapsProbeQMPSEVCapabilities Move the code out of virQEMUCapsInitQMPMonitor similarly to other functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-04-02 10:31:31 +00:00
return 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
}
qemu: Drop qemuFeatureNoEffect We already have virQEMUCapsCPUFilterFeatures for filtering features which QEMU does not know about. Let's move osxsave and ospke from qemuFeatureNoEffect there. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-06 12:39:52 +00:00
/*
* Filter for features which should never be passed to QEMU. Either because
* QEMU never supported them or they were dropped as they never did anything
* useful.
*/
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,
cpu_conf: Pass policy to CPU feature filtering callbacks Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-07 15:25:47 +00:00
virCPUFeaturePolicy policy G_GNUC_UNUSED,
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") ||
qemu: Drop qemuFeatureNoEffect We already have virQEMUCapsCPUFilterFeatures for filtering features which QEMU does not know about. Let's move osxsave and ospke from qemuFeatureNoEffect there. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-06 12:39:52 +00:00
STREQ(name, "mbm_local") ||
STREQ(name, "osxsave") ||
STREQ(name, "ospke"))
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
return false;
return true;
}
qemu: Add APIs for translating CPU features So far we always used libvirt's name of each CPU feature relying on backward compatible aliases in QEMU. The new translation table can be used whenever QEMU mandates or prefers canonical feature names. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-06 07:27:18 +00:00
typedef struct _virQEMUCapsCPUFeatureTranslationTable virQEMUCapsCPUFeatureTranslationTable;
typedef virQEMUCapsCPUFeatureTranslationTable *virQEMUCapsCPUFeatureTranslationTablePtr;
struct _virQEMUCapsCPUFeatureTranslationTable {
const char *libvirt;
const char *qemu;
};
virQEMUCapsCPUFeatureTranslationTable virQEMUCapsCPUFeaturesX86[] = {
{"cmp_legacy", "cmp-legacy"},
{"ds_cpl", "ds-cpl"},
{"fxsr_opt", "fxsr-opt"},
{"kvm_pv_eoi", "kvm-pv-eoi"},
{"kvm_pv_unhalt", "kvm-pv-unhalt"},
{"lahf_lm", "lahf-lm"},
{"nodeid_msr", "nodeid-msr"},
{"pclmuldq", "pclmulqdq"},
{"perfctr_core", "perfctr-core"},
{"perfctr_nb", "perfctr-nb"},
{"tsc_adjust", "tsc-adjust"},
{NULL, NULL}
};
static const char *
virQEMUCapsCPUFeatureTranslate(virQEMUCapsPtr qemuCaps,
const char *feature,
bool reversed)
{
virQEMUCapsCPUFeatureTranslationTablePtr table = NULL;
virQEMUCapsCPUFeatureTranslationTablePtr entry;
if (ARCH_IS_X86(qemuCaps->arch))
table = virQEMUCapsCPUFeaturesX86;
qemu_command: Use canonical names of CPU features When building QEMU command line, we should use the preferred spelling of each CPU feature without relying on compatibility aliases (which may be removed at some point). The "unavailable-features" CPU property is used as a witness for the correct names of the features in our translation table. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-07 13:00:28 +00:00
if (!table ||
!feature ||
!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CANONICAL_CPU_FEATURES))
qemu: Add APIs for translating CPU features So far we always used libvirt's name of each CPU feature relying on backward compatible aliases in QEMU. The new translation table can be used whenever QEMU mandates or prefers canonical feature names. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-06 07:27:18 +00:00
return feature;
for (entry = table; entry->libvirt; entry++) {
const char *key = reversed ? entry->qemu : entry->libvirt;
if (STREQ(feature, key))
return reversed ? entry->libvirt : entry->qemu;
}
return feature;
}
const char *
virQEMUCapsCPUFeatureToQEMU(virQEMUCapsPtr qemuCaps,
const char *feature)
{
return virQEMUCapsCPUFeatureTranslate(qemuCaps, feature, false);
}
const char *
virQEMUCapsCPUFeatureFromQEMU(virQEMUCapsPtr qemuCaps,
const char *feature)
{
return virQEMUCapsCPUFeatureTranslate(qemuCaps, feature, 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: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
cpu->model = g_strdup(modelInfo->name);
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
cpu->features = g_new0(virCPUFeatureDef, modelInfo->nprops);
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: Translate feature names from query-cpu-model-expansion By default query-cpu-model-expansion only reports canonical names of all CPU features. We do some magic and call the command twice to get all possible spellings of the features, but being able to consume canonical names will allow us to drop this magic. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:54:53 +00:00
const char *name = virQEMUCapsCPUFeatureFromQEMU(qemuCaps, prop->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
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: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
feature->name = g_strdup(name);
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_capabilities: Inroduce virQEMUCapsGetCPUModelX86Data The code for transforming qemuMonitorCPUModelInfo data from QEMU into virCPUDefPtr consumable by virCPU* APIs was hidden inside virQEMUCapsInitCPUModelX86. This patch moves it into a new function to make it usable in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 08:39:17 +00:00
virCPUDataPtr
qemu: Translate feature names from query-cpu-model-expansion By default query-cpu-model-expansion only reports canonical names of all CPU features. We do some magic and call the command twice to get all possible spellings of the features, but being able to consume canonical names will allow us to drop this magic. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:54:53 +00:00
virQEMUCapsGetCPUModelX86Data(virQEMUCapsPtr qemuCaps,
qemuMonitorCPUModelInfoPtr model,
qemu_capabilities: Inroduce virQEMUCapsGetCPUModelX86Data The code for transforming qemuMonitorCPUModelInfo data from QEMU into virCPUDefPtr consumable by virCPU* APIs was hidden inside virQEMUCapsInitCPUModelX86. This patch moves it into a new function to make it usable in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 08:39:17 +00:00
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
{
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_capabilities: Inroduce virQEMUCapsGetCPUModelX86Data The code for transforming qemuMonitorCPUModelInfo data from QEMU into virCPUDefPtr consumable by virCPU* APIs was hidden inside virQEMUCapsInitCPUModelX86. This patch moves it into a new function to make it usable in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 08:39:17 +00:00
virCPUDataPtr data = NULL;
virCPUDataPtr ret = NULL;
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
size_t i;
if (!(data = virCPUDataNew(VIR_ARCH_X86_64)))
goto cleanup;
for (i = 0; i < model->nprops; i++) {
qemuMonitorCPUPropertyPtr prop = model->props + i;
qemu: Translate feature names from query-cpu-model-expansion By default query-cpu-model-expansion only reports canonical names of all CPU features. We do some magic and call the command twice to get all possible spellings of the features, but being able to consume canonical names will allow us to drop this magic. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:54:53 +00:00
const char *name = virQEMUCapsCPUFeatureFromQEMU(qemuCaps, prop->name);
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
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;
cpu: Introduce virCPUDataAddFeature This is a generic replacement for the former virCPUx86DataAddFeature, which worked on the generic virCPUDataPtr anyway. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-18 08:09:31 +00:00
if (virCPUDataAddFeature(data, 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:
qemu: Translate feature names from query-cpu-model-expansion By default query-cpu-model-expansion only reports canonical names of all CPU features. We do some magic and call the command twice to get all possible spellings of the features, but being able to consume canonical names will allow us to drop this magic. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:54:53 +00:00
if (STREQ(name, "vendor") &&
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
virCPUx86DataSetVendor(data, prop->value.string) < 0)
goto cleanup;
break;
case QEMU_MONITOR_CPU_PROPERTY_NUMBER:
qemu: Translate feature names from query-cpu-model-expansion By default query-cpu-model-expansion only reports canonical names of all CPU features. We do some magic and call the command twice to get all possible spellings of the features, but being able to consume canonical names will allow us to drop this magic. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:54:53 +00:00
if (STREQ(name, "family"))
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
sigFamily = prop->value.number;
qemu: Translate feature names from query-cpu-model-expansion By default query-cpu-model-expansion only reports canonical names of all CPU features. We do some magic and call the command twice to get all possible spellings of the features, but being able to consume canonical names will allow us to drop this magic. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:54:53 +00:00
else if (STREQ(name, "model"))
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
sigModel = prop->value.number;
qemu: Translate feature names from query-cpu-model-expansion By default query-cpu-model-expansion only reports canonical names of all CPU features. We do some magic and call the command twice to get all possible spellings of the features, but being able to consume canonical names will allow us to drop this magic. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:54:53 +00:00
else if (STREQ(name, "stepping"))
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
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;
qemu: use g_steal_pointer instead of VIR_STEAL_PTR Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-16 11:43:18 +00:00
ret = g_steal_pointer(&data);
qemu_capabilities: Inroduce virQEMUCapsGetCPUModelX86Data The code for transforming qemuMonitorCPUModelInfo data from QEMU into virCPUDefPtr consumable by virCPU* APIs was hidden inside virQEMUCapsInitCPUModelX86. This patch moves it into a new function to make it usable in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 08:39:17 +00:00
cleanup:
virCPUDataFree(data);
return ret;
}
/**
* 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,
qemuMonitorCPUModelInfoPtr model,
virCPUDefPtr cpu,
bool migratable)
{
qemu: Copy CPU models in virQEMUCapsGetCPUDefinitions Rather than returning a direct pointer the list stored in qemuCaps the function now creates a new copy of the CPU models list. The main purpose of this seemingly useless change is to update callers to free the result returned by virQEMUCapsGetCPUDefinitions because the internals of this function will change significantly in the following patches. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-20 20:41:34 +00:00
g_autoptr(virDomainCapsCPUModels) cpuModels = NULL;
qemu_capabilities: Inroduce virQEMUCapsGetCPUModelX86Data The code for transforming qemuMonitorCPUModelInfo data from QEMU into virCPUDefPtr consumable by virCPU* APIs was hidden inside virQEMUCapsInitCPUModelX86. This patch moves it into a new function to make it usable in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 08:39:17 +00:00
virCPUDataPtr data = NULL;
int ret = -1;
if (!model)
return 1;
qemu: Translate feature names from query-cpu-model-expansion By default query-cpu-model-expansion only reports canonical names of all CPU features. We do some magic and call the command twice to get all possible spellings of the features, but being able to consume canonical names will allow us to drop this magic. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:54:53 +00:00
if (!(data = virQEMUCapsGetCPUModelX86Data(qemuCaps, model, migratable)))
qemu_capabilities: Inroduce virQEMUCapsGetCPUModelX86Data The code for transforming qemuMonitorCPUModelInfo data from QEMU into virCPUDefPtr consumable by virCPU* APIs was hidden inside virQEMUCapsInitCPUModelX86. This patch moves it into a new function to make it usable in tests. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 08:39:17 +00:00
goto cleanup;
qemu: Rename virQEMUCaps{Get,Fetch}CPUDefinitions The functions return virDomainCapsCPUModelsPtr and thus they should be called *CPUModels for consistency. Functions called *CPUDefinitions will work on qemuMonitorCPUDefsPtr. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-09 08:14:59 +00:00
cpuModels = virQEMUCapsGetCPUModels(qemuCaps, type, NULL, NULL);
qemu: Copy CPU models in virQEMUCapsGetCPUDefinitions Rather than returning a direct pointer the list stored in qemuCaps the function now creates a new copy of the CPU models list. The main purpose of this seemingly useless change is to update callers to free the result returned by virQEMUCapsGetCPUDefinitions because the internals of this function will change significantly in the following patches. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-20 20:41:34 +00:00
if (cpuDecode(cpu, data, cpuModels) < 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_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
qemuMonitorCPUModelInfoPtr modelInfo = virQEMUCapsGetCPUModelInfo(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_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
if (migratable && modelInfo && !modelInfo->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)) {
qemu_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
ret = virQEMUCapsInitCPUModelS390(qemuCaps, type, 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
cpu, migratable);
} else if (ARCH_IS_X86(qemuCaps->arch)) {
qemu_capabilities: Use virQEMUCapsGetCPUModelInfo Most places in qemu_capabilities.c which call virQEMUCapsGetHostCPUData actually need qemuMonitorCPUModelInfoPtr from QEMU caps. Let's use the wrapper introduced in the previous commit instead. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:00:53 +00:00
ret = virQEMUCapsInitCPUModelX86(qemuCaps, type, 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
cpu, migratable);
qemu: Don't use CPU from host capabilities as host-model on ARM We never supported host-model CPUs on ARM and we don't want to support them even once patches for direct detection of host CPU are merged. And since using host CPU definition for host-model CPUs exists only for backward compatibility, we should not use it for any host-model support added in the future. Such enhancement should exclusively use the result of query-cpu-model-expansion. Until proper host-model support is implemented for ARM (if ever), we need to make sure the detected host CPU is not accidentally used for host-model CPUs. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-05 16:35:26 +00:00
} else if (ARCH_IS_ARM(qemuCaps->arch)) {
ret = 2;
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
}
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)
{
conf: make virCPUDef into a ref counted struct Annoyingly there was no existing constructor, and identifying all the places which do a VIR_ALLOC(cpu) is a bit error prone. Hopefully this has found & converted them all. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-29 11:00:26 +00:00
virCPUDefPtr cpu = virCPUDefNew();
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
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: Copy CPU models in virQEMUCapsGetCPUDefinitions Rather than returning a direct pointer the list stored in qemuCaps the function now creates a new copy of the CPU models list. The main purpose of this seemingly useless change is to update callers to free the result returned by virQEMUCapsGetCPUDefinitions because the internals of this function will change significantly in the following patches. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-20 20:41:34 +00:00
g_autoptr(virDomainCapsCPUModels) cpuModels = 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
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: Rename virQEMUCaps{Get,Fetch}CPUDefinitions The functions return virDomainCapsCPUModelsPtr and thus they should be called *CPUModels for consistency. Functions called *CPUDefinitions will work on qemuMonitorCPUDefsPtr. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-09 08:14:59 +00:00
cpuModels = virQEMUCapsGetCPUModels(qemuCaps, type, NULL, NULL);
qemu: Copy CPU models in virQEMUCapsGetCPUDefinitions Rather than returning a direct pointer the list stored in qemuCaps the function now creates a new copy of the CPU models list. The main purpose of this seemingly useless change is to update callers to free the result returned by virQEMUCapsGetCPUDefinitions because the internals of this function will change significantly in the following patches. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-20 20:41:34 +00:00
hostCPU = virQEMUCapsProbeHostCPU(hostArch, cpuModels);
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)) {
qemu: Make virQEMUCapsProbeHostCPUForEmulator more generic The function is renamed as virQEMUCapsProbeHostCPU and it does not get the list of allowed CPU models from qemuCaps anymore. This is responsibility is moved to the caller. The result is just a very thin wrapper around virCPUGetHost mostly required mocking in tests. The generic function is used in place of a direct call to virCPUGetHost in virQEMUCapsInitHostCPUModel to make sure tests don't accidentally probe host CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2019-06-03 11:13:38 +00:00
if (!(fullCPU = virQEMUCapsProbeHostCPU(qemuCaps->arch, 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: Drop MSR features from host-model with old QEMU With QEMU versions which lack "unavailable-features" we use CPUID based detection of features which were enabled or disabled once QEMU starts. Thus using MSR features with host-model would result in all of them being marked as disabled in the active domain definition even though QEMU did not actually disable them. Let's make sure we add MSR features to host-model only when "unavailable-features" property is supported by QEMU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-19 20:22:09 +00:00
if (ARCH_IS_X86(qemuCaps->arch) &&
!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_UNAVAILABLE_FEATURES)) {
if (cpu &&
virCPUDefFilterFeatures(cpu, virCPUx86FeatureFilterDropMSR, NULL) < 0)
goto error;
if (migCPU &&
virCPUDefFilterFeatures(migCPU, virCPUx86FeatureFilterDropMSR, NULL) < 0)
goto error;
if (fullCPU &&
virCPUDefFilterFeatures(fullCPU, virCPUx86FeatureFilterDropMSR, NULL) < 0)
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_capabilities: Introduce virQEMUCapsGetCPUModelInfo This is a simple wrapper around virQEMUCapsGetHostCPUData usable in tests for getting qemuMonitorCPUModelInfoPtr from QEMU caps. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:01:34 +00:00
qemuMonitorCPUModelInfoPtr
virQEMUCapsGetCPUModelInfo(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
qemu: Drop virQEMUCapsGetHostCPUData It was very similar to virQEMUCapsGetAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:57:20 +00:00
return virQEMUCapsGetAccel(qemuCaps, type)->hostCPU.info;
qemu_capabilities: Introduce virQEMUCapsGetCPUModelInfo This is a simple wrapper around virQEMUCapsGetHostCPUData usable in tests for getting qemuMonitorCPUModelInfoPtr from QEMU caps. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-25 09:01:34 +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: Drop virQEMUCapsGetHostCPUData It was very similar to virQEMUCapsGetAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:57:20 +00:00
virQEMUCapsGetAccel(qemuCaps, type)->hostCPU.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
qemu: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
virQEMUCapsLoadHostCPUModelInfo(virQEMUCapsAccelPtr caps,
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,
qemu: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
const char *typeStr)
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;
VIR_XPATH_NODE_AUTORESTORE: remove semicolon from users Since the macro no longer includes the 'ignore_value' statement, stop putting another empty statement after it. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-07-28 19:47:48 +00:00
VIR_XPATH_NODE_AUTORESTORE(ctxt)
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
qemuMonitorCPUModelInfoPtr hostCPU = NULL;
qemu: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
g_autofree char *xpath = g_strdup_printf("./hostCPU[@type='%s']", typeStr);
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
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: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
if (!(hostCPUNode = virXPathNode(xpath, ctxt))) {
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;
}
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
hostCPU = g_new0(qemuMonitorCPUModelInfo, 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
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: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
hostCPU->props = g_new0(qemuMonitorCPUProperty, n);
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->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: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
caps->hostCPU.info = g_steal_pointer(&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
ret = 0;
cleanup:
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
qemu: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
virQEMUCapsLoadCPUModels(virQEMUCapsAccelPtr caps,
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,
qemu: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
const char *typeStr)
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: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
g_autoptr(qemuMonitorCPUDefs) defs = NULL;
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
g_autofree xmlNodePtr * nodes = NULL;
qemu: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
g_autofree char *xpath = g_strdup_printf("./cpu[@type='%s']", typeStr);
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
size_t i;
int n;
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;
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: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
if ((n = virXPathNodeSet(xpath, ctxt, &nodes)) < 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"));
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
return -1;
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: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
if (n == 0)
return 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
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
if (!(defs = qemuMonitorCPUDefsNew(n)))
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
return -1;
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: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
qemuMonitorCPUDefInfoPtr cpu = defs->cpus + 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;
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
g_autofree char * strUsable = NULL;
g_autofree xmlNodePtr * blockerNodes = NULL;
qemu: report whether a CPU model is deprecated in dom capabilities QEMU has the ability to mark CPUs as deprecated. This should be exposed to management applications in the domain capabilities. This attribute is only set when the model is actually deprecated. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 11:15:08 +00:00
g_autofree char *deprecated = NULL;
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
int nblockers;
if ((strUsable = virXMLPropString(nodes[i], "usable")) &&
(usable = virDomainCapsCPUUsableTypeFromString(strUsable)) < 0) {
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
virReportError(VIR_ERR_INTERNAL_ERROR,
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
_("unknown value '%s' in attribute 'usable'"),
strUsable);
return -1;
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
}
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
cpu->usable = usable;
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
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
if (!(cpu->name = virXMLPropString(nodes[i], "name"))) {
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",
_("missing cpu name in QEMU capabilities cache"));
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
return -1;
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: Store typename from query-cpu-definitions in qemuCaps We need to create a mapping between CPU model names and their corresponding QOM types. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-19 18:47:37 +00:00
cpu->type = virXMLPropString(nodes[i], "typename");
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"));
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
return -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
}
if (nblockers > 0) {
size_t j;
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
cpu->blockers = g_new0(char *, nblockers + 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
for (j = 0; j < nblockers; j++) {
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
if (!(cpu->blockers[j] = virXMLPropString(blockerNodes[j], "name"))) {
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
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing blocker name in QEMU "
"capabilities cache"));
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
return -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
}
}
}
qemu: report whether a CPU model is deprecated in dom capabilities QEMU has the ability to mark CPUs as deprecated. This should be exposed to management applications in the domain capabilities. This attribute is only set when the model is actually deprecated. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 11:15:08 +00:00
deprecated = virXMLPropString(nodes[i], "deprecated");
if (deprecated &&
STREQ(deprecated, "yes"))
cpu->deprecated = true;
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: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
caps->cpuModels = g_steal_pointer(&defs);
qemu: Use g_autofree in virQEMUCapsLoadCPUModels Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 12:55:26 +00:00
return 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
}
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
static int
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsLoadMachines(virQEMUCapsAccelPtr caps,
xmlXPathContextPtr ctxt,
const char *typeStr)
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
{
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
g_autofree char *xpath = g_strdup_printf("./machine[@type='%s']", typeStr);
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
g_autofree xmlNodePtr *nodes = NULL;
size_t i;
int n;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
if ((n = virXPathNodeSet(xpath, ctxt, &nodes)) < 0) {
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("failed to parse qemu capabilities machines"));
return -1;
}
if (n == 0)
return 0;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
caps->nmachineTypes = n;
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
caps->machineTypes = g_new0(virQEMUCapsMachineType, caps->nmachineTypes);
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
for (i = 0; i < n; i++) {
qemu_capabilities: Don't leak @str in virQEMUCapsLoadMachines() If parsing "maxCpus" attribute of <machine/> element fails an error is printed but the corresponding string is not freed. While it is very unlikely to happen (parsed XML is not user provided and we are the ones generating it), it is possible. Instead of freeing the variable in the error path explicitly, let's declare it as g_autofree. And while I'm at it, let's bring it into the loop where it's used. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-02-09 15:29:39 +00:00
g_autofree char *str = NULL;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
if (!(caps->machineTypes[i].name = virXMLPropString(nodes[i], "name"))) {
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing machine name in QEMU capabilities cache"));
return -1;
}
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
caps->machineTypes[i].alias = virXMLPropString(nodes[i], "alias");
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
str = virXMLPropString(nodes[i], "maxCpus");
if (str &&
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virStrToLong_ui(str, NULL, 10, &(caps->machineTypes[i].maxCpus)) < 0) {
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("malformed machine cpu count in QEMU capabilities cache"));
return -1;
}
VIR_FREE(str);
str = virXMLPropString(nodes[i], "hotplugCpus");
if (STREQ_NULLABLE(str, "yes"))
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
caps->machineTypes[i].hotplugCpus = true;
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
VIR_FREE(str);
str = virXMLPropString(nodes[i], "default");
if (STREQ_NULLABLE(str, "yes"))
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
caps->machineTypes[i].qemuDefault = true;
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
VIR_FREE(str);
qemu: Probe for default CPU types QEMU 4.2.0 will report default CPU types used by each machine type and we will want to start using it. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-07-18 17:21:55 +00:00
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
str = virXMLPropString(nodes[i], "numaMemSupported");
if (STREQ_NULLABLE(str, "yes"))
caps->machineTypes[i].numaMemSupported = true;
VIR_FREE(str);
qemu: Probe for default CPU types QEMU 4.2.0 will report default CPU types used by each machine type and we will want to start using it. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-07-18 17:21:55 +00:00
caps->machineTypes[i].defaultCPU = virXMLPropString(nodes[i], "defaultCPU");
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
caps->machineTypes[i].defaultRAMid = virXMLPropString(nodes[i], "defaultRAMid");
qemu_capabilities: Parse "deprecated" in virQEMUCapsLoadMachines() properly A <machine/> element can have "deprecated" attribute that corresponds to 'deprecated' member of _virQEMUCapsMachineType struct. But the member is of boolean type. Therefore, the string returned by virXMLPropString() must be freed. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-02-09 15:36:17 +00:00
str = virXMLPropString(nodes[i], "deprecated");
if (STREQ_NULLABLE(str, "yes"))
caps->machineTypes[i].deprecated = true;
VIR_FREE(str);
qemu: Split out virQEMUCapsLoadCache All the code for loading machine type data was moved to a standalone virQEMUCapsLoadMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:05:45 +00:00
}
return 0;
}
qemu: Add virQEMUCaps{Load,Format}Accel The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 08:24:46 +00:00
static int
virQEMUCapsLoadAccel(virQEMUCapsPtr qemuCaps,
xmlXPathContextPtr ctxt,
virDomainVirtType type)
{
qemu: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
virQEMUCapsAccelPtr caps = virQEMUCapsGetAccel(qemuCaps, type);
const char *typeStr = type == VIR_DOMAIN_VIRT_KVM ? "kvm" : "tcg";
if (virQEMUCapsLoadHostCPUModelInfo(caps, ctxt, typeStr) < 0)
qemu: Add virQEMUCaps{Load,Format}Accel The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 08:24:46 +00:00
return -1;
qemu: Refactor virQEMUCapsLoadAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsLoadAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 10:59:43 +00:00
if (virQEMUCapsLoadCPUModels(caps, ctxt, typeStr) < 0)
qemu: Add virQEMUCaps{Load,Format}Accel The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 08:24:46 +00:00
return -1;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
if (virQEMUCapsLoadMachines(caps, ctxt, typeStr) < 0)
return -1;
qemu: Add virQEMUCaps{Load,Format}Accel The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 08:24:46 +00:00
return 0;
}
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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
char *hostCPUSignature;
qemu: Introduce caching whether /dev/kvm is accessible Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU group. This reduces the overhead of the QEMU capabilities cache lookup. Before this patch there were many fork() calls used for checking whether /dev/kvm is accessible. Now we store the result whether /dev/kvm is accessible or not and we only need to re-run the virFileAccessibleAs check if the ctime of /dev/kvm has changed. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-10-29 17:34:58 +00:00
/* cache whether /dev/kvm is usable as runUid:runGuid */
virTristateBool kvmUsable;
time_t kvmCtime;
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: replace VIR_FREE with g_free in all vir*Free() functions Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2021-02-03 19:36:01 +00:00
g_free(priv->libDir);
g_free(priv->kernelVersion);
g_free(priv->hostCPUSignature);
g_free(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: 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)
{
Use g_autoptr instead of VIR_AUTOPTR Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOPTR aliases to g_autoptr. Replace all of its use by the GLib macro version. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 12:47:50 +00:00
g_autoptr(virSEVCapability) sev = NULL;
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))
return 0;
if (virXPathBoolean("boolean(./sev)", ctxt) == 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing SEV platform data in QEMU "
"capabilities cache"));
return -1;
}
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
sev = g_new0(virSEVCapability, 1);
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 (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;
}
qemu: use g_steal_pointer instead of VIR_STEAL_PTR Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-16 11:43:18 +00:00
qemuCaps->sevCapabilities = g_steal_pointer(&sev);
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
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>
qemu: store the emulator name in the capabilities XML We don't need this for any functional purpose, but when debugging hosts it is useful to know what binary a given capabilities XML document is associated with. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-10 10:23:14 +00:00
* <emulator>/some/path</emulator>
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
* <qemuctime>234235253</qemuctime>
qemu: Check for changes in qemu modules directory Add a configuration option for specifying location of the qemu modules directory, defaulting to /usr/lib64/qemu. Then use this location to check for changes in the directory, indicating that a qemu module has changed and capabilities need to be reprobed. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-20 21:52:17 +00:00
* <qemumoddirmtime>234235253</qemumoddirmtime>
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
* <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
* <flag name='foo'/>
* <flag name='bar'/>
* ...
* <cpu name="pentium3"/>
* ...
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
* <machine name='pc-1.0' alias='pc' hotplugCpus='yes' maxCpus='4' default='yes' numaMemSupported='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: don't continue loading caps if outdated The XML format used for QEMU capabilities is not required to be stable across releases, as we invalidate the cache whenever the libvirt binary changes. We none the less always try to parse te entire XML file before we do any validity checks. Thus if we change the format of any part of the data, or change permitted values for enums, then libvirtd logs will be spammed with errors. These are not in fact errors, but an expected scenario. This change makes the loading code validate the cache timestamp against the libvirtd timestamp immediately. If they don't match then we stop loading the rest of the XML file. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-18 13:44:16 +00:00
*
* Returns 0 on success, 1 if outdated, -1 on 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: 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: don't continue loading caps if outdated The XML format used for QEMU capabilities is not required to be stable across releases, as we invalidate the cache whenever the libvirt binary changes. We none the less always try to parse te entire XML file before we do any validity checks. Thus if we change the format of any part of the data, or change permitted values for enums, then libvirtd logs will be spammed with errors. These are not in fact errors, but an expected scenario. This change makes the loading code validate the cache timestamp against the libvirtd timestamp immediately. If they don't match then we stop loading the rest of the XML file. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-18 13:44:16 +00:00
const char *filename,
bool skipInvalidation)
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;
util: xml: Add wrapper for xmlXPathNewContext The wrapper reports libvirt errors for the libxml2 function so that the same does not have to be repeated over and over. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-09-09 06:33:58 +00:00
if (!(ctxt = virXMLXPathContextNew(doc)))
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;
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;
}
qemu: don't continue loading caps if outdated The XML format used for QEMU capabilities is not required to be stable across releases, as we invalidate the cache whenever the libvirt binary changes. We none the less always try to parse te entire XML file before we do any validity checks. Thus if we change the format of any part of the data, or change permitted values for enums, then libvirtd logs will be spammed with errors. These are not in fact errors, but an expected scenario. This change makes the loading code validate the cache timestamp against the libvirtd timestamp immediately. If they don't match then we stop loading the rest of the XML file. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-18 13:44:16 +00:00
if (virXPathLongLong("string(./selfctime)", ctxt, &l) < 0) {
virReportError(VIR_ERR_XML_ERROR, "%s",
_("missing selfctime in QEMU capabilities XML"));
goto cleanup;
}
qemuCaps->libvirtCtime = (time_t)l;
qemuCaps->libvirtVersion = 0;
if (virXPathULong("string(./selfvers)", ctxt, &lu) == 0)
qemuCaps->libvirtVersion = lu;
if (!skipInvalidation &&
(qemuCaps->libvirtCtime != virGetSelfLastChanged() ||
qemuCaps->libvirtVersion != LIBVIR_VERSION_NUMBER)) {
VIR_DEBUG("Outdated capabilities in %s: libvirt changed "
"(%lld vs %lld, %lu vs %lu), stopping load",
qemuCaps->binary,
(long long)qemuCaps->libvirtCtime,
(long long)virGetSelfLastChanged(),
(unsigned long)qemuCaps->libvirtVersion,
(unsigned long)LIBVIR_VERSION_NUMBER);
ret = 1;
goto cleanup;
}
qemu: store the emulator name in the capabilities XML We don't need this for any functional purpose, but when debugging hosts it is useful to know what binary a given capabilities XML document is associated with. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-10 10:23:14 +00:00
if (!(str = virXPathString("string(./emulator)", ctxt))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("missing emulator in QEMU capabilities cache"));
goto cleanup;
}
if (STRNEQ(str, qemuCaps->binary)) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Expected caps for '%s' but saw '%s'"),
qemuCaps->binary, str);
goto cleanup;
}
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
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
qemu: Check for changes in qemu modules directory Add a configuration option for specifying location of the qemu modules directory, defaulting to /usr/lib64/qemu. Then use this location to check for changes in the directory, indicating that a qemu module has changed and capabilities need to be reprobed. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-20 21:52:17 +00:00
if (virXPathLongLong("string(./qemumoddirmtime)", ctxt, &l) == 0)
qemuCaps->modDirMtime = (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 ((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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
qemuCaps->hostCPUSignature = virXPathString("string(./hostCPUSignature)", ctxt);
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);
Use g_strdup to fill in default values Replace: if (!s && VIR_STRDUP(s, str) < 0) goto; with: if (!s) s = g_strdup(str); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-18 13:08:21 +00:00
if (!qemuCaps->package)
qemuCaps->package = g_strdup("");
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
}
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: Add virQEMUCaps{Load,Format}Accel The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 08:24:46 +00:00
if (virQEMUCapsLoadAccel(qemuCaps, ctxt, VIR_DOMAIN_VIRT_KVM) < 0 ||
virQEMUCapsLoadAccel(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;
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;
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
qemuCaps->gicCapabilities = g_new0(virGICCapability, n);
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 < 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
qemu: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
if (virXPathBoolean("boolean(./kvmSupportsNesting)", ctxt) > 0)
qemuCaps->kvmSupportsNesting = true;
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
if (virXPathBoolean("boolean(./kvmSupportsSecureGuest)", ctxt) > 0)
qemuCaps->kvmSupportsSecureGuest = true;
qemu: don't continue loading caps if outdated The XML format used for QEMU capabilities is not required to be stable across releases, as we invalidate the cache whenever the libvirt binary changes. We none the less always try to parse te entire XML file before we do any validity checks. Thus if we change the format of any part of the data, or change permitted values for enums, then libvirtd logs will be spammed with errors. These are not in fact errors, but an expected scenario. This change makes the loading code validate the cache timestamp against the libvirtd timestamp immediately. If they don't match then we stop loading the rest of the XML file. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-18 13:44:16 +00:00
if (skipInvalidation)
qemuCaps->invalidation = false;
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
qemu: Refactor virQEMUCapsFormatAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsFormatAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 11:00:31 +00:00
virQEMUCapsFormatHostCPUModelInfo(virQEMUCapsAccelPtr caps,
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,
qemu: Refactor virQEMUCapsFormatAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsFormatAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 11:00:31 +00:00
const char *typeStr)
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: Refactor virQEMUCapsFormatAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsFormatAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 11:00:31 +00:00
qemuMonitorCPUModelInfoPtr model = caps->hostCPU.info;
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
qemu: Refactor virQEMUCapsFormatAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsFormatAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 11:00:31 +00:00
virQEMUCapsFormatCPUModels(virQEMUCapsAccelPtr caps,
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,
qemu: Refactor virQEMUCapsFormatAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsFormatAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 11:00:31 +00:00
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
{
qemu: Refactor virQEMUCapsFormatAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsFormatAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 11:00:31 +00:00
qemuMonitorCPUDefsPtr defs = caps->cpuModels;
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: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
if (!defs)
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
return;
qemu: Switch qemuCaps to use qemuMonitorCPUDefs We will need to keep some QEMU-specific data for each CPU model supported by a QEMU binary. Instead of complicating the generic virDomainCapsCPUModelsPtr, we can just directly store qemuMonitorCPUDefsPtr returned by the capabilities probing code. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-24 14:38:05 +00:00
for (i = 0; i < defs->ncpus; i++) {
qemuMonitorCPUDefInfoPtr cpu = defs->cpus + 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
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);
qemu: Store typename from query-cpu-definitions in qemuCaps We need to create a mapping between CPU model names and their corresponding QOM types. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-19 18:47:37 +00:00
virBufferEscapeString(buf, " typename='%s'", cpu->type);
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
if (cpu->usable) {
virBufferAsprintf(buf, " usable='%s'",
virDomainCapsCPUUsableTypeToString(cpu->usable));
}
qemu: report whether a CPU model is deprecated in dom capabilities QEMU has the ability to mark CPUs as deprecated. This should be exposed to management applications in the domain capabilities. This attribute is only set when the model is actually deprecated. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 11:15:08 +00:00
if (cpu->deprecated)
virBufferAddLit(buf, " deprecated='yes'");
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: Split out virQEMUCapsFormatCache All the code for formatting machine type data was moved to a standalone virQEMUCapsFormatMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:29:39 +00:00
static void
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsFormatMachines(virQEMUCapsAccelPtr caps,
virBufferPtr buf,
const char *typeStr)
qemu: Split out virQEMUCapsFormatCache All the code for formatting machine type data was moved to a standalone virQEMUCapsFormatMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:29:39 +00:00
{
size_t i;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
for (i = 0; i < caps->nmachineTypes; i++) {
virBufferAsprintf(buf, "<machine type='%s'", typeStr);
virBufferEscapeString(buf, " name='%s'",
caps->machineTypes[i].name);
qemu: Split out virQEMUCapsFormatCache All the code for formatting machine type data was moved to a standalone virQEMUCapsFormatMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:29:39 +00:00
virBufferEscapeString(buf, " alias='%s'",
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
caps->machineTypes[i].alias);
if (caps->machineTypes[i].hotplugCpus)
qemu: Split out virQEMUCapsFormatCache All the code for formatting machine type data was moved to a standalone virQEMUCapsFormatMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:29:39 +00:00
virBufferAddLit(buf, " hotplugCpus='yes'");
virBufferAsprintf(buf, " maxCpus='%u'",
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
caps->machineTypes[i].maxCpus);
if (caps->machineTypes[i].qemuDefault)
qemu: Split out virQEMUCapsFormatCache All the code for formatting machine type data was moved to a standalone virQEMUCapsFormatMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:29:39 +00:00
virBufferAddLit(buf, " default='yes'");
qemu: Probe for default CPU types QEMU 4.2.0 will report default CPU types used by each machine type and we will want to start using it. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-07-18 17:21:55 +00:00
virBufferEscapeString(buf, " defaultCPU='%s'",
caps->machineTypes[i].defaultCPU);
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
if (caps->machineTypes[i].numaMemSupported)
virBufferAddLit(buf, " numaMemSupported='yes'");
qemu: Track default-ram-id machine attribute The machine structure has another (optional) attribute: default-ram-id, which specifies the alias of the default RAM object. While the alias is private, it can never change in order to not break migration. QEMU uses the alias when allocating regular, not NUMA memory. In order to switch to new command line and maintain migration, save this ID. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-05-25 17:13:43 +00:00
virBufferEscapeString(buf, " defaultRAMid='%s'",
caps->machineTypes[i].defaultRAMid);
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
if (caps->machineTypes[i].deprecated)
virBufferAddLit(buf, " deprecated='yes'");
qemu: Split out virQEMUCapsFormatCache All the code for formatting machine type data was moved to a standalone virQEMUCapsFormatMachines function. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 16:29:39 +00:00
virBufferAddLit(buf, "/>\n");
}
}
qemu: Add virQEMUCaps{Load,Format}Accel The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 08:24:46 +00:00
static void
virQEMUCapsFormatAccel(virQEMUCapsPtr qemuCaps,
virBufferPtr buf,
virDomainVirtType type)
{
qemu: Refactor virQEMUCapsFormatAccel And make it use virQEMUCapsGetAccel once rather than repeating the same code in all functions called from virQEMUCapsFormatAccel. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 11:00:31 +00:00
virQEMUCapsAccelPtr caps = virQEMUCapsGetAccel(qemuCaps, type);
const char *typeStr = type == VIR_DOMAIN_VIRT_KVM ? "kvm" : "tcg";
virQEMUCapsFormatHostCPUModelInfo(caps, buf, typeStr);
virQEMUCapsFormatCPUModels(caps, buf, typeStr);
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsFormatMachines(caps, buf, typeStr);
qemu: Add virQEMUCaps{Load,Format}Accel The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 08:24:46 +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
{
qemu: use g_auto() for all virBuffers Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-02 22:26:41 +00:00
g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
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: store the emulator name in the capabilities XML We don't need this for any functional purpose, but when debugging hosts it is useful to know what binary a given capabilities XML document is associated with. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-10 10:23:14 +00:00
virBufferEscapeString(&buf, "<emulator>%s</emulator>\n",
qemuCaps->binary);
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: Check for changes in qemu modules directory Add a configuration option for specifying location of the qemu modules directory, defaulting to /usr/lib64/qemu. Then use this location to check for changes in the directory, indicating that a qemu module has changed and capabilities need to be reprobed. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-20 21:52:17 +00:00
if (qemuCaps->modDirMtime > 0) {
virBufferAsprintf(&buf, "<qemumoddirmtime>%llu</qemumoddirmtime>\n",
(long long)qemuCaps->modDirMtime);
}
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
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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
virBufferEscapeString(&buf, "<hostCPUSignature>%s</hostCPUSignature>\n",
qemuCaps->hostCPUSignature);
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: 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: Add virQEMUCaps{Load,Format}Accel The new functions are designed to load and format capabilities which depend on the accelerator (host CPU expansion and CPU models). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 08:24:46 +00:00
virQEMUCapsFormatAccel(qemuCaps, &buf, VIR_DOMAIN_VIRT_KVM);
qemu: Move machine type data in capabilities cache In preparation for making machine types dependent on the accelerator, the <machine> elements are formatted between <cpu type='kvm'> and <cpu type='tcg'>. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 07:04:58 +00:00
virQEMUCapsFormatAccel(qemuCaps, &buf, VIR_DOMAIN_VIRT_QEMU);
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: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
if (qemuCaps->kvmSupportsNesting)
virBufferAddLit(&buf, "<kvmSupportsNesting/>\n");
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
if (qemuCaps->kvmSupportsSecureGuest)
virBufferAddLit(&buf, "<kvmSupportsSecureGuest/>\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
virBufferAddLit(&buf, "</qemuCaps>\n");
Drop needless variable Instead of the following pattern: type ret; ... ret = func(); return ret; we can use: return func() directly. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-04 15:03:42 +00:00
return virBufferContentAndReset(&buf);
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
}
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,
qemu: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:33 +00:00
void *privData G_GNUC_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: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
/*
* Check whether IBM Secure Execution (S390) is enabled
*/
static bool
virQEMUCapsKVMSupportsSecureGuestS390(void)
{
g_autofree char *cmdline = NULL;
static const char *kValues[] = {"y", "Y", "on", "ON", "oN", "On", "1"};
if (!virFileIsDir("/sys/firmware/uv"))
return false;
if (virFileReadValueString(&cmdline, "/proc/cmdline") < 0)
return false;
/* we're prefix matching rather than equality matching here, because kernel
* would treat even something like prot_virt='yFOO' as enabled */
if (virKernelCmdlineMatchParam(cmdline, "prot_virt", kValues,
G_N_ELEMENTS(kValues),
VIR_KERNEL_CMDLINE_FLAGS_SEARCH_FIRST |
VIR_KERNEL_CMDLINE_FLAGS_CMP_PREFIX))
return true;
return false;
}
qemu: Check if AMD secure guest support is enabled Implement secure guest check for AMD SEV (Secure Encrypted Virtualization) in order to invalidate the qemu capabilities cache in case the availability of the feature changed. For AMD SEV the verification consists of: - checking if /sys/module/kvm_amd/parameters/sev contains the value '1': meaning SEV is enabled in the host kernel; - checking if /dev/sev exists Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:08 +00:00
/*
* Check whether AMD Secure Encrypted Virtualization (x86) is enabled
*/
static bool
virQEMUCapsKVMSupportsSecureGuestAMD(void)
{
g_autofree char *modValue = NULL;
if (virFileReadValueString(&modValue, "/sys/module/kvm_amd/parameters/sev") < 0)
return false;
if (modValue[0] != '1')
return false;
if (virFileExists(QEMU_DEV_SEV))
return true;
return false;
}
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
/*
* Check whether the secure guest functionality is enabled.
* See the specific architecture function for details on the verifications made.
*/
static bool
virQEMUCapsKVMSupportsSecureGuest(void)
{
virArch arch = virArchFromHost();
if (ARCH_IS_S390(arch))
return virQEMUCapsKVMSupportsSecureGuestS390();
qemu: Check if AMD secure guest support is enabled Implement secure guest check for AMD SEV (Secure Encrypted Virtualization) in order to invalidate the qemu capabilities cache in case the availability of the feature changed. For AMD SEV the verification consists of: - checking if /sys/module/kvm_amd/parameters/sev contains the value '1': meaning SEV is enabled in the host kernel; - checking if /dev/sev exists Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:08 +00:00
if (ARCH_IS_X86(arch))
return virQEMUCapsKVMSupportsSecureGuestAMD();
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
return false;
}
qemu: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
/* Check the kernel module parameters 'nested' file to determine if enabled
*
* Intel: 'kvm_intel' uses 'Y'
* AMD: 'kvm_amd' uses '1'
* PPC64: 'kvm_hv' uses 'Y'
* S390: 'kvm' uses '1'
*/
static bool
virQEMUCapsKVMSupportsNesting(void)
{
static char const * const kmod[] = {"kvm_intel", "kvm_amd",
"kvm_hv", "kvm"};
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *value = NULL;
qemu: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
int rc;
size_t i;
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
for (i = 0; i < G_N_ELEMENTS(kmod); i++) {
qemu: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
VIR_FREE(value);
rc = virFileReadValueString(&value, "/sys/module/%s/parameters/nested",
kmod[i]);
if (rc == -2)
continue;
if (rc < 0) {
virResetLastError();
return false;
}
if (value[0] == 'Y' || value[0] == 'y' || value[0] == '1')
return true;
}
return false;
}
qemu: Introduce caching whether /dev/kvm is accessible Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU group. This reduces the overhead of the QEMU capabilities cache lookup. Before this patch there were many fork() calls used for checking whether /dev/kvm is accessible. Now we store the result whether /dev/kvm is accessible or not and we only need to re-run the virFileAccessibleAs check if the ctime of /dev/kvm has changed. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-10-29 17:34:58 +00:00
/* Determine whether '/dev/kvm' is usable as QEMU user:QEMU group. */
static bool
virQEMUCapsKVMUsable(virQEMUCapsCachePrivPtr priv)
{
struct stat sb;
static const char *kvm_device = "/dev/kvm";
virTristateBool value;
virTristateBool cached_value = priv->kvmUsable;
time_t kvm_ctime;
time_t cached_kvm_ctime = priv->kvmCtime;
if (stat(kvm_device, &sb) < 0) {
if (errno != ENOENT) {
virReportSystemError(errno,
_("Failed to stat %s"), kvm_device);
}
return false;
}
kvm_ctime = sb.st_ctime;
if (kvm_ctime != cached_kvm_ctime) {
VIR_DEBUG("%s has changed (%lld vs %lld)", kvm_device,
(long long)kvm_ctime, (long long)cached_kvm_ctime);
cached_value = VIR_TRISTATE_BOOL_ABSENT;
}
if (cached_value != VIR_TRISTATE_BOOL_ABSENT)
return cached_value == VIR_TRISTATE_BOOL_YES;
if (virFileAccessibleAs(kvm_device, R_OK | W_OK,
priv->runUid, priv->runGid) == 0) {
value = VIR_TRISTATE_BOOL_YES;
} else {
value = VIR_TRISTATE_BOOL_NO;
}
/* There is a race window between 'stat' and
* 'virFileAccessibleAs'. However, since we're only interested in
* detecting changes *after* the virFileAccessibleAs check, we can
* neglect this here.
*/
priv->kvmCtime = kvm_ctime;
priv->kvmUsable = value;
return value == VIR_TRISTATE_BOOL_YES;
}
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: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
bool kvmSupportsNesting;
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: add explicit flag to skip qemu caps invalidation Currently if the binary path is NULL in the qemu capabilities object, cache invalidation is skipped. A future patch will ensure that the binary path is always non-NULL, so a way to explicitly skip invalidation is required. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 11:56:38 +00:00
if (!qemuCaps->invalidation)
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
if (!qemuCaps->binary)
return true;
qemu: Check for changes in qemu modules directory Add a configuration option for specifying location of the qemu modules directory, defaulting to /usr/lib64/qemu. Then use this location to check for changes in the directory, indicating that a qemu module has changed and capabilities need to be reprobed. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-20 21:52:17 +00:00
if (virFileExists(QEMU_MODDIR)) {
if (stat(QEMU_MODDIR, &sb) < 0) {
VIR_DEBUG("Failed to stat QEMU module directory '%s': %s",
QEMU_MODDIR,
g_strerror(errno));
return false;
}
if (sb.st_mtime != qemuCaps->modDirMtime) {
VIR_DEBUG("Outdated capabilities for '%s': QEMU modules "
"directory '%s' changed (%lld vs %lld)",
qemuCaps->binary, QEMU_MODDIR,
(long long)sb.st_mtime, (long long)qemuCaps->modDirMtime);
return false;
}
}
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) {
VIR_DEBUG("Failed to stat QEMU binary '%s': %s",
qemuCaps->binary,
Use g_strerror instead of virStrerror Remove lots of stack-allocated buffers. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-02-26 17:57:34 +00:00
g_strerror(errno));
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
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: Introduce caching whether /dev/kvm is accessible Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU group. This reduces the overhead of the QEMU capabilities cache lookup. Before this patch there were many fork() calls used for checking whether /dev/kvm is accessible. Now we store the result whether /dev/kvm is accessible or not and we only need to re-run the virFileAccessibleAs check if the ctime of /dev/kvm has changed. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-10-29 17:34:58 +00:00
kvmUsable = virQEMUCapsKVMUsable(priv);
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)) {
qemu: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
if (STRNEQ_NULLABLE(priv->hostCPUSignature, qemuCaps->hostCPUSignature)) {
VIR_DEBUG("Outdated capabilities for '%s': host CPU changed "
"('%s' vs '%s')",
qemuCaps->binary,
priv->hostCPUSignature,
qemuCaps->hostCPUSignature);
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 (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: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
kvmSupportsNesting = virQEMUCapsKVMSupportsNesting();
if (kvmSupportsNesting != qemuCaps->kvmSupportsNesting) {
VIR_DEBUG("Outdated capabilities for '%s': kvm kernel nested "
"value changed from %d",
qemuCaps->binary, qemuCaps->kvmSupportsNesting);
return false;
}
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
if (virQEMUCapsKVMSupportsSecureGuest() != qemuCaps->kvmSupportsSecureGuest) {
VIR_DEBUG("Outdated capabilities for '%s': kvm kernel secure guest "
"value changed from %d",
qemuCaps->binary, qemuCaps->kvmSupportsSecureGuest);
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;
}
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)
{
virQEMUCapsInitQMPArch: Refactor cleanup Switch to using the 'g_auto*' helpers. Signed-off-by: Yi Li <yili@winhong.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2021-03-10 07:46:29 +00:00
g_autofree char *archstr = NULL;
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 (!(archstr = qemuMonitorGetTargetArch(mon)))
virQEMUCapsInitQMPArch: Refactor cleanup Switch to using the 'g_auto*' helpers. Signed-off-by: Yi Li <yili@winhong.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2021-03-10 07:46:29 +00:00
return -1;
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);
virQEMUCapsInitQMPArch: Refactor cleanup Switch to using the 'g_auto*' helpers. Signed-off-by: Yi Li <yili@winhong.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2021-03-10 07:46:29 +00:00
return -1;
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
}
virQEMUCapsInitQMPArch: Refactor cleanup Switch to using the 'g_auto*' helpers. Signed-off-by: Yi Li <yili@winhong.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2021-03-10 07:46:29 +00:00
return 0;
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
*
* 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
qemu: caps: Separate capabilities based on qemu version virQEMUCapsInitQMPMonitor is massive now since it collects calls to the various probing functions and also version based capabilities. Split out the version based caps into a separate function. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:05:45 +00:00
/**
* virQEMUCapsInitQMPVersionCaps:
* @qemuCaps: QEMU capabilities
*
* Add all QEMU capabilities based on version of QEMU.
*/
static void
virQEMUCapsInitQMPVersionCaps(virQEMUCapsPtr qemuCaps)
{
if (qemuCaps->version >= 1006000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_DEVICE_VIDEO_PRIMARY);
/* vmport option is supported v2.2.0 onwards */
if (qemuCaps->version >= 2002000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_VMPORT_OPT);
/* -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);
/* vhost-user supports multi-queue from v2.4.0 onwards,
* but there is no way to query for that capability */
if (qemuCaps->version >= 2004000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_VHOSTUSER_MULTIQUEUE);
/* smm option is supported from v2.4.0 */
if (qemuCaps->version >= 2004000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_SMM_OPT);
/* sdl -gl option is supported from v2.4.0 (qemu commit id 0b71a5d5) */
if (qemuCaps->version >= 2004000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_SDL_GL);
/* Since 2.4.50 ARM virt machine supports gic-version option */
if (qemuCaps->version >= 2004050)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACH_VIRT_GIC_VERSION);
/* no way to query if -machine kernel_irqchip supports split */
if (qemuCaps->version >= 2006000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_KERNEL_IRQCHIP_SPLIT);
/* 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);
}
/* '-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);
/* no way to query for -numa dist */
if (qemuCaps->version >= 2010000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NUMA_DIST);
/* 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: Introduce QEMU_CAPS_TCG Since QEMU 2.10 it is possible to disable TCG when building QEMU. Introduce a capability that reflects this. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-28 09:04:14 +00:00
/* TCG couldn't be disabled nor queried until QEMU 2.10 */
if (qemuCaps->version < 2010000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_TCG);
qemu: stop passing -enable-fips to QEMU >= 5.2.0 Use of the -enable-fips option is being deprecated in QEMU >= 5.2.0. If FIPS compliance is required, QEMU must be built with libcrypt which will unconditionally enforce it. Thus there is no need for libvirt to pass -enable-fips to modern QEMU. Unfortunately there was never any way to probe for -enable-fips in the first instance, it was enabled by libvirt based on version number originally, and then later unconditionally enabled when libvirt dropped support for older QEMU. Similarly we now use a version number check to decide when to stop passing -enable-fips. Note that the qemu-5.2 capabilities are currently from the pre-release version and will be updated once qemu-5.2 is released. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-10-20 16:48:59 +00:00
/* -enable-fips is deprecated in QEMU 5.2.0, and QEMU
* should be built with gcrypt to achieve FIPS compliance
* automatically / implicitly
*/
if (qemuCaps->version < 5002000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_ENABLE_FIPS);
qemu: caps: Separate capabilities based on qemu version virQEMUCapsInitQMPMonitor is massive now since it collects calls to the various probing functions and also version based capabilities. Split out the version based caps into a separate function. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:05:45 +00:00
}
qemu: capabilities: Lock out incremental backup capability without blockdev Blockdev is required to do incremental backups properly. Add a helper function for locking out capabilities and export it to allow re-doing the processing if a different code path modifies capabilities. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-11-25 11:59:51 +00:00
/**
* virQEMUCapsInitProcessCapsInterlock:
* @qemuCaps: QEMU capabilities
*
* A capability which requires a different capability being present in order
* for libvirt to be able to drive it properly should be processed here.
*/
void
virQEMUCapsInitProcessCapsInterlock(virQEMUCapsPtr qemuCaps)
{
qemu: capabilities: Enable QEMU_CAPS_INCREMENTAL_BACKUP For incremental backup we need QEMU_CAPS_BLOCKDEV, QEMU_CAPS_BLOCKDEV_REOPEN, QEMU_CAPS_MIGRATION_PARAM_BLOCK_BITMAP_MAPPING. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-16 11:57:49 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_BLOCKDEV) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_BLOCKDEV_REOPEN) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_MIGRATION_PARAM_BLOCK_BITMAP_MAPPING))
virQEMUCapsSet(qemuCaps, QEMU_CAPS_INCREMENTAL_BACKUP);
qemu: add QEMU_CAPS_STORAGE_WERROR Detect the werror property on SCSI and virtio disks. But clear it if the QEMU supports usb-storage device without it also supporting this option for usb-storage. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2020-04-01 08:22:30 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_USB_STORAGE) &&
!virQEMUCapsGet(qemuCaps, QEMU_CAPS_USB_STORAGE_WERROR)) {
virQEMUCapsClear(qemuCaps, QEMU_CAPS_STORAGE_WERROR);
}
qemu: caps: Enable QEMU_CAPS_BLOCKDEV_HOSTDEV_SCSI Enable it when regular QEMU_CAPS_BLOCKDEV is present. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-08 13:02:56 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_BLOCKDEV))
virQEMUCapsSet(qemuCaps, QEMU_CAPS_BLOCKDEV_HOSTDEV_SCSI);
qemu: capabilities: Lock out incremental backup capability without blockdev Blockdev is required to do incremental backups properly. Add a helper function for locking out capabilities and export it to allow re-doing the processing if a different code path modifies capabilities. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-11-25 11:59:51 +00:00
}
qemu: caps: Aggregate all caps post-processing into a function Some caps are cleared according to some more advanced logic after detection. Split all that logic out into virQEMUCapsInitProcessCaps. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:12:09 +00:00
/**
* virQEMUCapsInitProcessCaps:
* @qemuCaps: QEMU capabilities
*
* Some capability bits are enabled or disabled according to specific logic.
* This function collects all capability processing after the capabilities
* are detected.
*/
static void
virQEMUCapsInitProcessCaps(virQEMUCapsPtr qemuCaps)
{
/* '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);
}
/* 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. */
qemu: caps: Don't check capability before clearing it Checking whether a qemu capability set right before clearing it without any other logic doesn't make sense. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-11-24 08:55:42 +00:00
if (qemuCaps->version < 2009000)
qemu: caps: Aggregate all caps post-processing into a function Some caps are cleared according to some more advanced logic after detection. Split all that logic out into virQEMUCapsInitProcessCaps. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:12:09 +00:00
virQEMUCapsClear(qemuCaps, QEMU_CAPS_DEVICE_NVDIMM);
if (ARCH_IS_X86(qemuCaps->arch) &&
qemu: Probe for migrtability support in CPU expansion Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-02 23:05:36 +00:00
virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION)) {
qemu: caps: Aggregate all caps post-processing into a function Some caps are cleared according to some more advanced logic after detection. Split all that logic out into virQEMUCapsInitProcessCaps. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:12:09 +00:00
virQEMUCapsSet(qemuCaps, QEMU_CAPS_CPU_CACHE);
qemu: Probe for migrtability support in CPU expansion Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-02 23:05:36 +00:00
/* Old x86 QEMU supported migratable:false property in
* query-cpu-model-expansion arguments even though it was not properly
* advertised as a CPU property.
*/
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_MIGRATABLE) ||
qemuCaps->version < 2012000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION_MIGRATABLE);
}
qemu: caps: Aggregate all caps post-processing into a function Some caps are cleared according to some more advanced logic after detection. Split all that logic out into virQEMUCapsInitProcessCaps. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:12:09 +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);
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CCW_CSSID_UNRESTRICTED))
virQEMUCapsClear(qemuCaps, QEMU_CAPS_DEVICE_VFIO_CCW);
}
qemu_command: Use canonical names of CPU features When building QEMU command line, we should use the preferred spelling of each CPU feature without relying on compatibility aliases (which may be removed at some point). The "unavailable-features" CPU property is used as a witness for the correct names of the features in our translation table. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-07 13:00:28 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_UNAVAILABLE_FEATURES))
virQEMUCapsSet(qemuCaps, QEMU_CAPS_CANONICAL_CPU_FEATURES);
qemu: enable blockdev support Now that all pieces are in place (hopefully) let's enable -blockdev. We base the capability on presence of the fix for 'auto-read-only' on files so that blockdev works properly, mandate that qemu supports explicit SCSI id strings to avoid ABI regression and that the fix for 'savevm' is present so that internal snapshots work. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-07 10:45:19 +00:00
/* To avoid guest ABI regression, blockdev shall be enabled only when
* we are able to pass the custom 'device_id' for SCSI disks and cdroms. */
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_BLOCK_FILE_AUTO_READONLY_DYNAMIC) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_SCSI_DISK_DEVICE_ID) &&
virQEMUCapsGet(qemuCaps, QEMU_CAPS_SAVEVM_MONITOR_NODES))
virQEMUCapsSet(qemuCaps, QEMU_CAPS_BLOCKDEV);
qemu: capabilities: Lock out incremental backup capability without blockdev Blockdev is required to do incremental backups properly. Add a helper function for locking out capabilities and export it to allow re-doing the processing if a different code path modifies capabilities. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-11-25 11:59:51 +00:00
qemu: add capabilities for the three ESP family SCSI controllers Probing for the NCR53C90 controller is a little unusual. The qom-list-types QMP command returns a list of all types known to the QEMU binary. It does not distinguish devices which are user creatable from those which are built-in. Any QEMU target that supports PCI will have the DC390 / AM53C974 devices because they are PCI based. Due to code dependencies in QEMU though, existence of these two devices will also pull in the NCR53C90 device (called just 'esp' in QEMU). The NCR53C90 is not user-creatable and can only be used when built-in to the machine type. This is only the case on sparc machines, and certain mips64 and m68k machines. IOW, we don't rely on qom-list-types as a guide for existence of NCR53C90, as it shouldn't really exist in most QEMU binaries. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-11-18 16:37:54 +00:00
/* We can't probe "esp" as a type via virQEMUCapsObjectTypes
* array as it is only usable when builtin to the machine type
*/
if (qemuCaps->arch == VIR_ARCH_SPARC ||
qemuCaps->arch == VIR_ARCH_M68K ||
qemuCaps->arch == VIR_ARCH_MIPS)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_SCSI_NCR53C90);
qemu: capabilities: Lock out incremental backup capability without blockdev Blockdev is required to do incremental backups properly. Add a helper function for locking out capabilities and export it to allow re-doing the processing if a different code path modifies capabilities. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-11-25 11:59:51 +00:00
virQEMUCapsInitProcessCapsInterlock(qemuCaps);
qemu: caps: Aggregate all caps post-processing into a function Some caps are cleared according to some more advanced logic after detection. Split all that logic out into virQEMUCapsInitProcessCaps. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:12:09 +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;
util: hash: Retire 'virHashTable' in favor of 'GHashTable' Don't hide our use of GHashTable behind our typedef. This will also promote the use of glibs hash function directly. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Matt Coleman <matt@datto.com>
2020-10-22 17:04:18 +00:00
GHashTable *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: Decide whether to query schema in virQEMUCapsProbeQMPSchemaCapabilities Move the check out of virQEMUCapsInitQMPMonitor similarly to other functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-04-02 10:31:31 +00:00
if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_QUERY_QMP_SCHEMA))
return 0;
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;
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsQMPSchemaQueries); i++) {
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
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);
}
qemu: caps: Probe events from 'query-qmp-schema' rather than 'query-events' QEMU plans to deprecate 'query-events' as it's non-extensible. Events are also described by 'query-qmp-schema' so we can use that one instead. This patch adds detection of events to virQEMUCapsProbeQMPSchemaCapabilities using the same structure declaring them for the old approach (virQEMUCapsEvents). This is possible as the name is the same in the QMP schema and our detector supports that trivially. For any complex queries virQEMUCapsQMPSchemaQueries can be used in the future. For now we still call 'query-events' and discard the result so that it's obvious that the tests pass. This will be cleaned up later. https://bugzilla.redhat.com/show_bug.cgi?id=1673320 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-02-07 11:50:27 +00:00
/* probe also for basic event support */
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsEvents); i++) {
qemu: caps: Probe events from 'query-qmp-schema' rather than 'query-events' QEMU plans to deprecate 'query-events' as it's non-extensible. Events are also described by 'query-qmp-schema' so we can use that one instead. This patch adds detection of events to virQEMUCapsProbeQMPSchemaCapabilities using the same structure declaring them for the old approach (virQEMUCapsEvents). This is possible as the name is the same in the QMP schema and our detector supports that trivially. For any complex queries virQEMUCapsQMPSchemaQueries can be used in the future. For now we still call 'query-events' and discard the result so that it's obvious that the tests pass. This will be cleaned up later. https://bugzilla.redhat.com/show_bug.cgi?id=1673320 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-02-07 11:50:27 +00:00
entry = virQEMUCapsEvents + i;
if (virQEMUQAPISchemaPathExists(entry->value, schema))
virQEMUCapsSet(qemuCaps, entry->flag);
}
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
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: Add virQEMUCapsGetVirtType convenience function Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-22 21:50:43 +00:00
virDomainVirtType
virQEMUCapsGetVirtType(virQEMUCapsPtr qemuCaps)
{
virDomainVirtType type;
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))
type = VIR_DOMAIN_VIRT_KVM;
else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_TCG))
type = VIR_DOMAIN_VIRT_QEMU;
else
type = VIR_DOMAIN_VIRT_NONE;
return type;
}
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 major, minor, micro;
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *package = NULL;
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
virQEMUCapsAccelPtr accel;
virDomainVirtType type;
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
/* @mon is supposed to be locked by callee */
qemu: caps: Remove pointless debug message in virQEMUCapsInitQMPMonitor Failure of qemuMonitorGetVersion is fatal now that we only support QMP based qemus. Remove the debug message since we report an error already. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:28:56 +00:00
if (qemuMonitorGetVersion(mon, &major, &minor, &micro, &package) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
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
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: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
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->version = major * 1000000 + minor * 1000 + micro;
qemu: use g_steal_pointer instead of VIR_STEAL_PTR Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-16 11:43:18 +00:00
qemuCaps->package = g_steal_pointer(&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
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: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
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: 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);
src: fix word spell typos Signed-off-by: Fangge Jin <fjin@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-07-09 04:42:21 +00:00
/* initiate all capabilities based on qemu version */
qemu: caps: Separate capabilities based on qemu version virQEMUCapsInitQMPMonitor is massive now since it collects calls to the various probing functions and also version based capabilities. Split out the version based caps into a separate function. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:05:45 +00:00
virQEMUCapsInitQMPVersionCaps(qemuCaps);
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
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)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
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)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
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
qemu: Add virQEMUCapsGetVirtType convenience function Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-22 21:50:43 +00:00
type = virQEMUCapsGetVirtType(qemuCaps);
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
accel = virQEMUCapsGetAccel(qemuCaps, type);
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)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
virQEMUCapsProbeQMPDevices: Split up into logical chunks The function was parsing 'qom-list-types' and then also calling function which parses 'device-list-properties' and also 'qom-list-properties'. Split it up into individual functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-05-06 14:53:31 +00:00
if (virQEMUCapsProbeQMPObjectTypes(qemuCaps, mon) < 0)
return -1;
if (virQEMUCapsProbeQMPDeviceProperties(qemuCaps, mon) < 0)
return -1;
if (virQEMUCapsProbeQMPObjectProperties(qemuCaps, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
if (virQEMUCapsProbeQMPMachineTypes(qemuCaps, type, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
if (virQEMUCapsProbeQMPMachineProps(qemuCaps, type, mon) < 0)
qemu: Move call to virQEMUCapsProbeQMPMachineProps() We're going to need information about available machine types when probing machine type properties soon, and that means we have to change the order we call QMP commands. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2019-05-16 13:46:58 +00:00
return -1;
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
if (virQEMUCapsProbeQMPCPUDefinitions(qemuCaps, accel, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
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 (virQEMUCapsProbeQMPTPM(qemuCaps, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
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 (virQEMUCapsProbeQMPCommandLine(qemuCaps, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
qemu: Add RDMA migration capabilities
2014-09-11 12:11:54 +00:00
if (virQEMUCapsProbeQMPMigrationCapabilities(qemuCaps, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
qemu: Decide whether to query schema in virQEMUCapsProbeQMPSchemaCapabilities Move the check out of virQEMUCapsInitQMPMonitor similarly to other functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-04-02 10:31:31 +00:00
if (virQEMUCapsProbeQMPSchemaCapabilities(qemuCaps, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
qemu: Decide whether check GIC caps in virQEMUCapsProbeQMPGICCapabilities Move the check out of virQEMUCapsInitQMPMonitor similarly to other functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-04-02 10:31:31 +00:00
if (virQEMUCapsProbeQMPGICCapabilities(qemuCaps, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -1;
qemu: Move SEV capability handling into virQEMUCapsProbeQMPSEVCapabilities Move the code out of virQEMUCapsInitQMPMonitor similarly to other functions. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-04-02 10:31:31 +00:00
if (virQEMUCapsProbeQMPSEVCapabilities(qemuCaps, mon) < 0)
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return -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
qemu: caps: Aggregate all caps post-processing into a function Some caps are cleared according to some more advanced logic after detection. Split all that logic out into virQEMUCapsInitProcessCaps. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:12:09 +00:00
virQEMUCapsInitProcessCaps(qemuCaps);
qemu: caps: Add lockout for -blockdev if QEMU_CAPS_SCSI_DISK_DEVICE_ID is not present Avoid regressions by disallowing the BLOCKDEV capability. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-01-28 16:12:01 +00:00
qemu: Probe host CPU after capabilities The way we call query-cpu-model-expansion will rely on some capabilities bits. Let's make sure all capabilities are set before probing host CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:16:51 +00:00
/* The following probes rely on other previously probed capabilities.
* No capabilities bits should be set below this point. */
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
if (virQEMUCapsProbeQMPHostCPU(qemuCaps, accel, mon, type) < 0)
qemu: Probe host CPU after capabilities The way we call query-cpu-model-expansion will rely on some capabilities bits. Let's make sure all capabilities are set before probing host CPU. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-06-17 11:16:51 +00:00
return -1;
qemu: caps: Remove cleanup section in virQEMUCapsInitQMPMonitor Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-29 08:25:21 +00:00
return 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
}
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
qemu: Remove ATTRIBUTE_UNUSED from 'qemuCaps' of virQEMUCapsInitQMPMonitorTCG It's actually used. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-04-02 11:29:18 +00:00
virQEMUCapsInitQMPMonitorTCG(virQEMUCapsPtr qemuCaps,
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
qemuMonitorPtr mon)
{
qemu: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, VIR_DOMAIN_VIRT_QEMU);
if (virQEMUCapsProbeQMPCPUDefinitions(qemuCaps, accel, mon) < 0)
qemu: Remove cleanup section of virQEMUCapsInitQMPMonitorTCG There's nothing to clean up. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-04-02 11:31:52 +00:00
return -1;
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: Refactor probing of accelerator dependent data To avoid duplicating code which selects the right virQEMUCapsAccel data to be filled during probing. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-23 14:48:17 +00:00
if (virQEMUCapsProbeQMPHostCPU(qemuCaps, accel, mon, VIR_DOMAIN_VIRT_QEMU) < 0)
qemu: Remove cleanup section of virQEMUCapsInitQMPMonitorTCG There's nothing to clean up. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-04-02 11:31:52 +00:00
return -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
qemu: add machines & arch to fake test capabilities cache Currently the virQEMUCapsPtr objects are just empty. Future patches are going to expect them to contain real data. Start off by populating the machine types and arch information. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-02 12:19:44 +00:00
if (virQEMUCapsProbeQMPMachineTypes(qemuCaps, VIR_DOMAIN_VIRT_QEMU, mon) < 0)
qemu: Probe machine types for both KVM and TCG Almost all TCG query-machines replies match KVM. The only exceptions are 4.2.0 replies on s390x which differ in the reported default CPU type. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:21:46 +00:00
return -1;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
qemu: Remove cleanup section of virQEMUCapsInitQMPMonitorTCG There's nothing to clean up. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2019-04-02 11:31:52 +00:00
return 0;
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
}
qemu_capabilities: Log probe failure in virQEMUCapsInitQMPSingle Let's push the call to virQEMUCapsLogProbeFailure down the stack to where the probing failure is detected. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 13:50:39 +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 },
};
virLogMessage(&virLogSelf,
VIR_LOG_WARN,
__FILE__, __LINE__, __func__,
meta,
_("Failed to probe capabilities for %s: %s"),
binary, virGetLastErrorMessage());
}
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
qemu_capabilities: Refactor virQEMUCapsInitQMP The function contains two almost identical parts. Let's consolidate them into a single helper function and call it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-11 16:06:31 +00:00
virQEMUCapsInitQMPSingle(virQEMUCapsPtr qemuCaps,
const char *libDir,
uid_t runUid,
gid_t runGid,
bool onlyTCG)
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_capabilities.c: use g_autoptr() in virQEMUCapsInitQMPSingle() Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20200717211556.1024748-6-danielhb413@gmail.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2020-07-17 21:15:56 +00:00
g_autoptr(qemuProcessQMP) proc = 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
int ret = -1;
qemu_process: Refer to proc not cmd in process code s/cmd/proc/ in process code imported from qemu_capabilities. Signed-off-by: Chris Venteicher <cventeic@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-01-13 00:50:03 +00:00
if (!(proc = qemuProcessQMPNew(qemuCaps->binary, libDir,
qemu_process: Hide qmperr inside qemuProcessQMP Keep the pointer to QEMU stderr output in qemuProcessQMP struct instead of requiring the caller to provide it (and free it). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 14:00:42 +00:00
runUid, runGid, onlyTCG)))
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 cleanup;
qemu_process: Introduce qemuProcessQMPStart This is a replacement for qemuProcessQMPRun to make the name consistent with qemuProcessStart. The original qemuProcessQMPRun function is renamed as qemuProcessQMPLaunch and becomes one of the simpler functions called from the main qemuProcessQMPStart entry point. The following patches will move parts of the code in qemuProcessQMPLaunch to the other functions (qemuProcessQMPInit and qemuProcessQMPConnectMonitor). Signed-off-by: Chris Venteicher <cventeic@redhat.com> Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-01-13 00:50:10 +00:00
if (qemuProcessQMPStart(proc) < 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
goto cleanup;
qemu_capabilities: Refactor virQEMUCapsInitQMP The function contains two almost identical parts. Let's consolidate them into a single helper function and call it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-11 16:06:31 +00:00
if (onlyTCG)
ret = virQEMUCapsInitQMPMonitorTCG(qemuCaps, proc->mon);
else
ret = virQEMUCapsInitQMPMonitor(qemuCaps, proc->mon);
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
cleanup:
qemu_capabilities: Log probe failure in virQEMUCapsInitQMPSingle Let's push the call to virQEMUCapsLogProbeFailure down the stack to where the probing failure is detected. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 13:50:39 +00:00
if (ret < 0)
virQEMUCapsLogProbeFailure(qemuCaps->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
return ret;
}
qemu_capabilities: Refactor virQEMUCapsInitQMP The function contains two almost identical parts. Let's consolidate them into a single helper function and call it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-11 16:06:31 +00:00
static int
virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
const char *libDir,
uid_t runUid,
qemu_process: Hide qmperr inside qemuProcessQMP Keep the pointer to QEMU stderr output in qemuProcessQMP struct instead of requiring the caller to provide it (and free it). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 14:00:42 +00:00
gid_t runGid)
qemu_capabilities: Refactor virQEMUCapsInitQMP The function contains two almost identical parts. Let's consolidate them into a single helper function and call it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-11 16:06:31 +00:00
{
qemu_process: Hide qmperr inside qemuProcessQMP Keep the pointer to QEMU stderr output in qemuProcessQMP struct instead of requiring the caller to provide it (and free it). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 14:00:42 +00:00
if (virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, false) < 0)
qemu_capabilities: Refactor virQEMUCapsInitQMP The function contains two almost identical parts. Let's consolidate them into a single helper function and call it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-11 16:06:31 +00:00
return -1;
/*
* If KVM was enabled during the first probe, we need to explicitly probe
* for TCG capabilities by asking the same binary again and turning KVM
* off.
*/
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) &&
qemu: Fix capabilities probing with TCG Only probe QEMU binary with accel=tcg if TCG is not disabled. Similarly, only add a VIR_DOMAIN_VIRT_QEMU guest if TCG is available. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-22 21:50:42 +00:00
virQEMUCapsGet(qemuCaps, QEMU_CAPS_TCG) &&
qemu_process: Hide qmperr inside qemuProcessQMP Keep the pointer to QEMU stderr output in qemuProcessQMP struct instead of requiring the caller to provide it (and free it). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 14:00:42 +00:00
virQEMUCapsInitQMPSingle(qemuCaps, libDir, runUid, runGid, true) < 0)
qemu_capabilities: Refactor virQEMUCapsInitQMP The function contains two almost identical parts. Let's consolidate them into a single helper function and call it twice. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-11 16:06:31 +00:00
return -1;
return 0;
}
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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
const char *hostCPUSignature,
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;
qemu: add qemu caps constructor which takes binary name Simplify repeated code patterns by providing a new constructor taking the QEMU binary name. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 12:28:57 +00:00
if (!(qemuCaps = virQEMUCapsNewBinary(binary)))
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
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: Check for changes in qemu modules directory Add a configuration option for specifying location of the qemu modules directory, defaulting to /usr/lib64/qemu. Then use this location to check for changes in the directory, indicating that a qemu module has changed and capabilities need to be reprobed. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-20 21:52:17 +00:00
if (virFileExists(QEMU_MODDIR)) {
if (stat(QEMU_MODDIR, &sb) < 0) {
virReportSystemError(errno, _("Cannot check QEMU module directory %s"),
QEMU_MODDIR);
goto error;
}
qemuCaps->modDirMtime = sb.st_mtime;
}
qemu_process: Hide qmperr inside qemuProcessQMP Keep the pointer to QEMU stderr output in qemuProcessQMP struct instead of requiring the caller to provide it (and free it). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-02-12 14:00:42 +00:00
if (virQEMUCapsInitQMP(qemuCaps, libDir, runUid, runGid) < 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 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
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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
qemuCaps->hostCPUSignature = g_strdup(hostCPUSignature);
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: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
qemuCaps->kernelVersion = g_strdup(kernelVersion);
qemu: Add check for whether KVM nesting is enabled Support for nested KVM is handled via a kernel module configuration parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). While it's possible to fetch the kmod config values via virKModConfig, unfortunately that is the static value and we need to get the current/dynamic value from the kernel file system. So this patch adds a new API virHostKVMSupportsNesting that will search the 3 kernel modules to get the nesting value and check if it is 'Y' (or 'y' just in case) to return a true/false whether the KVM kernel supports nesting. We need to do this in order to handle cases where adjustments to the value are made after libvirtd is started to force a refetch of the latest QEMU capabilities since the correct CPU settings need to be made for a guest to add the "vmx=on" to/for the guest config. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-11-12 19:58:09 +00:00
qemuCaps->kvmSupportsNesting = virQEMUCapsKVMSupportsNesting();
qemu: Check if s390 secure guest support is enabled This patch introduces a common function to verify if the availability of the so-called Secure Guest feature on the host has changed in order to invalidate the qemu capabilities cache. It can be used as an entry point for verification on different architectures. For s390 the verification consists of: - checking if /sys/firmware/uv is available: meaning the HW facility is available and the host OS supports it; - checking if the kernel cmdline contains 'prot_virt=1': meaning the host OS wants to use the feature. Whenever the availability of the feature does not match the secure guest flag in the cache then libvirt will re-build it in order to pick up the new set of capabilities available. Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-15 08:28:07 +00:00
qemuCaps->kvmSupportsSecureGuest = virQEMUCapsKVMSupportsSecureGuest();
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
}
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);
qemu: remove unneeded labels Remove unneeded, easy to remove goto labels (cleanup|error|done|...). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-01-06 21:57:40 +00:00
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: 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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
priv->hostCPUSignature,
virhostcpu.c: skip non x86 hosts in virHostCPUGetMicrocodeVersion() Non-x86 archs does not have a 'microcode' version like x86. This is covered already inside the function - just return 0 if no microcode is found. Regardless of that, a read of /proc/cpuinfo is always made. Each read will invoke the kernel to fill in the CPU details every time. Now let's consider a non-x86 host, like a Power 9 server with 128 CPUs. Each /proc/cpuinfo read will need to fetch data for each CPU and it won't even matter because we know beforehand that PowerPC chips don't have microcode information. We can do better for non-x86 hosts by skipping this process entirely. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-08-24 13:27:53 +00:00
virHostCPUGetMicrocodeVersion(priv->hostArch),
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,
qemu: don't continue loading caps if outdated The XML format used for QEMU capabilities is not required to be stable across releases, as we invalidate the cache whenever the libvirt binary changes. We none the less always try to parse te entire XML file before we do any validity checks. Thus if we change the format of any part of the data, or change permitted values for enums, then libvirtd logs will be spammed with errors. These are not in fact errors, but an expected scenario. This change makes the loading code validate the cache timestamp against the libvirtd timestamp immediately. If they don't match then we stop loading the rest of the XML file. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-18 13:44:16 +00:00
void *privData,
bool *outdated)
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: add qemu caps constructor which takes binary name Simplify repeated code patterns by providing a new constructor taking the QEMU binary name. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 12:28:57 +00:00
virQEMUCapsPtr qemuCaps = virQEMUCapsNewBinary(binary);
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: don't continue loading caps if outdated The XML format used for QEMU capabilities is not required to be stable across releases, as we invalidate the cache whenever the libvirt binary changes. We none the less always try to parse te entire XML file before we do any validity checks. Thus if we change the format of any part of the data, or change permitted values for enums, then libvirtd logs will be spammed with errors. These are not in fact errors, but an expected scenario. This change makes the loading code validate the cache timestamp against the libvirtd timestamp immediately. If they don't match then we stop loading the rest of the XML file. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-18 13:44:16 +00:00
int ret;
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: don't continue loading caps if outdated The XML format used for QEMU capabilities is not required to be stable across releases, as we invalidate the cache whenever the libvirt binary changes. We none the less always try to parse te entire XML file before we do any validity checks. Thus if we change the format of any part of the data, or change permitted values for enums, then libvirtd logs will be spammed with errors. These are not in fact errors, but an expected scenario. This change makes the loading code validate the cache timestamp against the libvirtd timestamp immediately. If they don't match then we stop loading the rest of the XML file. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-18 13:44:16 +00:00
ret = virQEMUCapsLoadCache(priv->hostArch, qemuCaps, filename, false);
if (ret < 0)
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
goto error;
qemu: don't continue loading caps if outdated The XML format used for QEMU capabilities is not required to be stable across releases, as we invalidate the cache whenever the libvirt binary changes. We none the less always try to parse te entire XML file before we do any validity checks. Thus if we change the format of any part of the data, or change permitted values for enums, then libvirtd logs will be spammed with errors. These are not in fact errors, but an expected scenario. This change makes the loading code validate the cache timestamp against the libvirtd timestamp immediately. If they don't match then we stop loading the rest of the XML file. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-18 13:44:16 +00:00
if (ret == 1) {
*outdated = true;
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
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: remove unneeded labels Remove unneeded, easy to remove goto labels (cleanup|error|done|...). Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-01-06 21:57:40 +00:00
return NULL;
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,
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
G_N_ELEMENTS(virQEMUCapsMachineBLAHFilter) }, */
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
{ "", NULL, 0 },
};
void
virQEMUCapsFilterByMachineType(virQEMUCapsPtr qemuCaps,
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
virDomainVirtType virtType,
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)
{
size_t i;
if (!machineType)
return;
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
for (i = 0; i < G_N_ELEMENTS(virQEMUCapsMachineFilter); i++) {
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 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: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
if (!virQEMUCapsGetMachineHotplugCpus(qemuCaps, virtType, machineType))
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
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: Don't cache microcode version My earlier commit be46f61326 was incomplete. It removed caching of microcode version in the CPU driver, which means the capabilities XML will see the correct microcode version. But it is also cached in the QEMU capabilities cache where it is used to detect whether we need to reprobe QEMU. By missing the second place, the original commit be46f61326 made the situation even worse since libvirt would report correct microcode version while still using the old host CPU model (visible in domain capabilities XML). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 19:21:05 +00:00
gid_t runGid)
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: Use g_strdup_printf() instead of virAsprintf() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-10-22 13:26:14 +00:00
capsCacheDir = g_strdup_printf("%s/capabilities", cacheDir);
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: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
priv = g_new0(virQEMUCapsCachePriv, 1);
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: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
priv->libDir = g_strdup(libDir);
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
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: Invalidate capabilities when host CPU changes The host CPU related info stored in the capabilities cache is no longer valid after the host CPU changes. This is not a frequent situation in real world, but it can easily happen in nested scenarios when a disk image is started with various CPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1778819 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-15 20:00:29 +00:00
if (virHostCPUGetSignature(&priv->hostCPUSignature) < 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
priv->runUid = runUid;
priv->runGid = runGid;
qemu: Introduce caching whether /dev/kvm is accessible Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU group. This reduces the overhead of the QEMU capabilities cache lookup. Before this patch there were many fork() calls used for checking whether /dev/kvm is accessible. Now we store the result whether /dev/kvm is accessible or not and we only need to re-run the virFileAccessibleAs check if the ctime of /dev/kvm has changed. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2018-10-29 17:34:58 +00:00
priv->kvmUsable = VIR_TRISTATE_BOOL_ABSENT;
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: Use g_strdup_printf() instead of virAsprintf() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-10-22 13:26:14 +00:00
if (uname(&uts) == 0)
priv->kernelVersion = g_strdup_printf("%s %s", uts.release, uts.version);
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
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
{
qemu: Don't cache microcode version My earlier commit be46f61326 was incomplete. It removed caching of microcode version in the CPU driver, which means the capabilities XML will see the correct microcode version. But it is also cached in the QEMU capabilities cache where it is used to detect whether we need to reprobe QEMU. By missing the second place, the original commit be46f61326 made the situation even worse since libvirt would report correct microcode version while still using the old host CPU model (visible in domain capabilities XML). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 19:21:05 +00:00
virQEMUCapsCachePrivPtr priv = virFileCacheGetPriv(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
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
virhostcpu.c: skip non x86 hosts in virHostCPUGetMicrocodeVersion() Non-x86 archs does not have a 'microcode' version like x86. This is covered already inside the function - just return 0 if no microcode is found. Regardless of that, a read of /proc/cpuinfo is always made. Each read will invoke the kernel to fill in the CPU details every time. Now let's consider a non-x86 host, like a Power 9 server with 128 CPUs. Each /proc/cpuinfo read will need to fetch data for each CPU and it won't even matter because we know beforehand that PowerPC chips don't have microcode information. We can do better for non-x86 hosts by skipping this process entirely. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-08-24 13:27:53 +00:00
priv->microcodeVersion = virHostCPUGetMicrocodeVersion(priv->hostArch);
qemu: Don't cache microcode version My earlier commit be46f61326 was incomplete. It removed caching of microcode version in the CPU driver, which means the capabilities XML will see the correct microcode version. But it is also cached in the QEMU capabilities cache where it is used to detect whether we need to reprobe QEMU. By missing the second place, the original commit be46f61326 made the situation even worse since libvirt would report correct microcode version while still using the old host CPU model (visible in domain capabilities XML). Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-04-12 19:21:05 +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,
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
virDomainVirtType virtType,
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;
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
virQEMUCapsFilterByMachineType(ret, virtType, 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 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;
qemu: fixing auto-detecting binary in domain capabilities The virConnectGetDomainCapabilities API accepts either a binary path to the emulator, or desired guest arch. If guest arch is not given, then the host arch is assumed. In the case where the binary is not given, the code tried to find the emulator binary in the existing list of cached emulator capabilities. This is not valid since we switched to lazy population of the cache in: commit 3dd91af01f30c5bda6328454ef49f3afece755d6 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Mon Dec 2 13:04:26 2019 +0000 qemu: stop creating capabilities at driver startup As a result of this change, if there are no persistent guests defined using the requested guest architecture, virConnectGetDomainCapabilities will fail to find an emulator binary. The solution is to stop relying on the cached capabilities to find the binary and instead use the same logic we use to pick default a binary per arch when populating capabilities. Tested-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-17 13:25:02 +00:00
virArch hostarch = virArchFromHost();
virArch arch = hostarch;
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
virDomainVirtType capsType;
qemu_capabilities.c: modernize virQEMUCapsCacheLookupDefault Use g_autoptr() in qemuCaps to get rid of a virObjectUnref call, a 'cleanup' label and the 'ret' pointer. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-22 13:32:33 +00:00
g_autoptr(virQEMUCaps) qemuCaps = NULL;
qemu: fixing auto-detecting binary in domain capabilities The virConnectGetDomainCapabilities API accepts either a binary path to the emulator, or desired guest arch. If guest arch is not given, then the host arch is assumed. In the case where the binary is not given, the code tried to find the emulator binary in the existing list of cached emulator capabilities. This is not valid since we switched to lazy population of the cache in: commit 3dd91af01f30c5bda6328454ef49f3afece755d6 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Mon Dec 2 13:04:26 2019 +0000 qemu: stop creating capabilities at driver startup As a result of this change, if there are no persistent guests defined using the requested guest architecture, virConnectGetDomainCapabilities will fail to find an emulator binary. The solution is to stop relying on the cached capabilities to find the binary and instead use the same logic we use to pick default a binary per arch when populating capabilities. Tested-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-17 13:25:02 +00:00
virArch arch_from_caps;
g_autofree char *probedbinary = NULL;
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 (virttypeStr &&
(virttype = virDomainVirtTypeFromString(virttypeStr)) < 0) {
virReportError(VIR_ERR_INVALID_ARG,
_("unknown virttype: %s"), virttypeStr);
qemu_capabilities.c: modernize virQEMUCapsCacheLookupDefault Use g_autoptr() in qemuCaps to get rid of a virObjectUnref call, a 'cleanup' label and the 'ret' pointer. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-22 13:32:33 +00:00
return NULL;
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 (archStr &&
(arch = virArchFromString(archStr)) == VIR_ARCH_NONE) {
virReportError(VIR_ERR_INVALID_ARG,
_("unknown architecture: %s"), archStr);
qemu_capabilities.c: modernize virQEMUCapsCacheLookupDefault Use g_autoptr() in qemuCaps to get rid of a virObjectUnref call, a 'cleanup' label and the 'ret' pointer. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-22 13:32:33 +00:00
return NULL;
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
}
qemu: fixing auto-detecting binary in domain capabilities The virConnectGetDomainCapabilities API accepts either a binary path to the emulator, or desired guest arch. If guest arch is not given, then the host arch is assumed. In the case where the binary is not given, the code tried to find the emulator binary in the existing list of cached emulator capabilities. This is not valid since we switched to lazy population of the cache in: commit 3dd91af01f30c5bda6328454ef49f3afece755d6 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Mon Dec 2 13:04:26 2019 +0000 qemu: stop creating capabilities at driver startup As a result of this change, if there are no persistent guests defined using the requested guest architecture, virConnectGetDomainCapabilities will fail to find an emulator binary. The solution is to stop relying on the cached capabilities to find the binary and instead use the same logic we use to pick default a binary per arch when populating capabilities. Tested-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-17 13:25:02 +00:00
if (!binary) {
probedbinary = virQEMUCapsGetDefaultEmulator(hostarch, arch);
binary = probedbinary;
}
qemu: fix missing error reports in capabilities probing The "virsh domcapabilities --arch ppc64" command will fail with no error message set if qemu-system-ppc64 is not currently installed. This is because virQEMUCapsCacheLookup() does not report any error message if not capabilities can be obtained from the cache. Almost all methods calling this expected an error to be set on failure. Once that's fixed though, we see a further bug which is that virQEMUCapsCacheLookupDefault() is passing a NULL binary path to virQEMUCapsCacheLookup(), so we need to catch that too. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-15 12:43:26 +00:00
if (!binary) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("unable to find any emulator to serve '%s' architecture"),
archStr);
return NULL;
}
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
qemu: fixing auto-detecting binary in domain capabilities The virConnectGetDomainCapabilities API accepts either a binary path to the emulator, or desired guest arch. If guest arch is not given, then the host arch is assumed. In the case where the binary is not given, the code tried to find the emulator binary in the existing list of cached emulator capabilities. This is not valid since we switched to lazy population of the cache in: commit 3dd91af01f30c5bda6328454ef49f3afece755d6 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Mon Dec 2 13:04:26 2019 +0000 qemu: stop creating capabilities at driver startup As a result of this change, if there are no persistent guests defined using the requested guest architecture, virConnectGetDomainCapabilities will fail to find an emulator binary. The solution is to stop relying on the cached capabilities to find the binary and instead use the same logic we use to pick default a binary per arch when populating capabilities. Tested-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-17 13:25:02 +00:00
if (!(qemuCaps = virQEMUCapsCacheLookup(cache, binary)))
qemu_capabilities.c: modernize virQEMUCapsCacheLookupDefault Use g_autoptr() in qemuCaps to get rid of a virObjectUnref call, a 'cleanup' label and the 'ret' pointer. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-22 13:32:33 +00:00
return NULL;
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
qemu: fixing auto-detecting binary in domain capabilities The virConnectGetDomainCapabilities API accepts either a binary path to the emulator, or desired guest arch. If guest arch is not given, then the host arch is assumed. In the case where the binary is not given, the code tried to find the emulator binary in the existing list of cached emulator capabilities. This is not valid since we switched to lazy population of the cache in: commit 3dd91af01f30c5bda6328454ef49f3afece755d6 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Mon Dec 2 13:04:26 2019 +0000 qemu: stop creating capabilities at driver startup As a result of this change, if there are no persistent guests defined using the requested guest architecture, virConnectGetDomainCapabilities will fail to find an emulator binary. The solution is to stop relying on the cached capabilities to find the binary and instead use the same logic we use to pick default a binary per arch when populating capabilities. Tested-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-17 13:25:02 +00:00
arch_from_caps = virQEMUCapsGetArch(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
qemu: fixing auto-detecting binary in domain capabilities The virConnectGetDomainCapabilities API accepts either a binary path to the emulator, or desired guest arch. If guest arch is not given, then the host arch is assumed. In the case where the binary is not given, the code tried to find the emulator binary in the existing list of cached emulator capabilities. This is not valid since we switched to lazy population of the cache in: commit 3dd91af01f30c5bda6328454ef49f3afece755d6 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Mon Dec 2 13:04:26 2019 +0000 qemu: stop creating capabilities at driver startup As a result of this change, if there are no persistent guests defined using the requested guest architecture, virConnectGetDomainCapabilities will fail to find an emulator binary. The solution is to stop relying on the cached capabilities to find the binary and instead use the same logic we use to pick default a binary per arch when populating capabilities. Tested-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-01-17 13:25:02 +00:00
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));
qemu_capabilities.c: modernize virQEMUCapsCacheLookupDefault Use g_autoptr() in qemuCaps to get rid of a virObjectUnref call, a 'cleanup' label and the 'ret' pointer. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-22 13:32:33 +00:00
return NULL;
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
}
qemu: Add virQEMUCapsGetVirtType convenience function Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-22 21:50:43 +00:00
capsType = virQEMUCapsGetVirtType(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 (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);
qemu_capabilities.c: modernize virQEMUCapsCacheLookupDefault Use g_autoptr() in qemuCaps to get rid of a virObjectUnref call, a 'cleanup' label and the 'ret' pointer. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-22 13:32:33 +00:00
return NULL;
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
}
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
if (machine) {
/* Turn @machine into canonical name */
machine = virQEMUCapsGetCanonicalMachine(qemuCaps, virttype, machine);
if (!virQEMUCapsIsMachineSupported(qemuCaps, virttype, machine)) {
virReportError(VIR_ERR_INVALID_ARG,
_("the machine '%s' is not supported by emulator '%s'"),
machine, binary);
qemu_capabilities.c: modernize virQEMUCapsCacheLookupDefault Use g_autoptr() in qemuCaps to get rid of a virObjectUnref call, a 'cleanup' label and the 'ret' pointer. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-22 13:32:33 +00:00
return NULL;
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
}
} else {
machine = virQEMUCapsGetPreferredMachine(qemuCaps, virttype);
}
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 (retArch)
*retArch = arch;
if (retVirttype)
*retVirttype = virttype;
if (retMachine)
*retMachine = machine;
qemu_capabilities.c: modernize virQEMUCapsCacheLookupDefault Use g_autoptr() in qemuCaps to get rid of a virObjectUnref call, a 'cleanup' label and the 'ret' pointer. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2020-06-22 13:32:33 +00:00
return g_steal_pointer(&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
}
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: 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: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
virQEMUCapsGetPreferredMachine(virQEMUCapsPtr qemuCaps,
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virDomainVirtType virtType)
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: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, virtType);
if (!accel->nmachineTypes)
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
return NULL;
qemu: Make probed machine types depend on accelerator Some specifics of machine types may depend on the accelerator and thus the data should be moved to virQEMUCapsAccel. The TCG machine types are just copied from the ones probed for KVM to simplify the changes to qemucapabilitiestest data files. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 12:19:38 +00:00
return accel->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,
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
bool secure,
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: domcaps: use virTristateBool for 'supported' Switch most 'supported' handling to use virTristateBool, so eventually we can handle the ABSENT state. For now the XML formatter treats ABSENT the same as FALSE, so there's no functional output change. This will be addressed in later patches Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-08 23:03:20 +00:00
capsLoader->supported = VIR_TRISTATE_BOOL_YES;
qemu: fill in virCapsEnum 'report' Set report=true for all enums currently formatted in the XML Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-06 23:21:45 +00:00
capsLoader->type.report = true;
capsLoader->readonly.report = true;
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
capsLoader->secure.report = 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
qemu: capabilities: use g_new0 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-10-05 10:25:44 +00:00
capsLoader->values.values = g_new0(char *, nfirmwares);
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
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;
qemu_capabilities: Put only unique FW images into domcaps In the domain capabilities XML there are FW image paths printed. There are two sources for the image paths (in order of preference): 1) firmware descriptor files - as returned by qemuFirmwareGetSupported() 2) a compile time list of FW:NRAM pairs which can be overridden in qemu.conf If either of those contains a duplicate FW image path (which is a valid use case) it is printed twice in the capabilities XML. While it's technically not a bug, it doesn't look good. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Tested-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-09-12 11:07:31 +00:00
size_t j;
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;
}
qemu_capabilities: Put only unique FW images into domcaps In the domain capabilities XML there are FW image paths printed. There are two sources for the image paths (in order of preference): 1) firmware descriptor files - as returned by qemuFirmwareGetSupported() 2) a compile time list of FW:NRAM pairs which can be overridden in qemu.conf If either of those contains a duplicate FW image path (which is a valid use case) it is printed twice in the capabilities XML. While it's technically not a bug, it doesn't look good. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Tested-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-09-12 11:07:31 +00:00
/* Put only unique FW images onto the list */
for (j = 0; j < capsLoader->values.nvalues; j++) {
if (STREQ(filename, capsLoader->values.values[j]))
break;
}
if (j != capsLoader->values.nvalues)
continue;
qemu: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
capsLoader->values.values[capsLoader->values.nvalues] = g_strdup(filename);
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);
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(capsLoader->secure,
VIR_TRISTATE_BOOL_NO);
if (secure)
VIR_DOMAIN_CAPS_ENUM_SET(capsLoader->secure,
VIR_TRISTATE_BOOL_YES);
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,
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
const char *machine,
virArch arch,
bool privileged,
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;
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
uint64_t autoFirmwares = 0;
bool secure = false;
qemu: Use FW descriptors to report FW image paths Now that we have qemuFirmwareGetSupported() so that it also returns a list of FW image paths, we can use it to report them in domain capabilities instead of the old time default list. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 09:29:05 +00:00
virFirmwarePtr *firmwaresAlt = NULL;
size_t nfirmwaresAlt = 0;
int ret = -1;
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: domcaps: use virTristateBool for 'supported' Switch most 'supported' handling to use virTristateBool, so eventually we can handle the ABSENT state. For now the XML formatter treats ABSENT the same as FALSE, so there's no functional output change. This will be addressed in later patches Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-08 23:03:20 +00:00
os->supported = VIR_TRISTATE_BOOL_YES;
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
os->firmware.report = true;
qemu_firmware: Extend qemuFirmwareGetSupported to return FW paths The qemuFirmwareGetSupported() function is called from qemu driver to generate domain capabilities XML based on FW descriptor files. However, the function currently reports only some features from domcapabilities XML and not actual FW image paths. The paths reported in the domcapabilities XML are still from pre-FW descriptor era and therefore the XML might be a bit confusing. For instance, it may say that secure boot is supported but secboot enabled FW is not in the listed FW image paths. To resolve this problem, change qemuFirmwareGetSupported() so that it also returns a list of FW images (we have the list anyway). Luckily, we already have a structure to represent a FW image - virFirmware. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 12:56:32 +00:00
if (qemuFirmwareGetSupported(machine, arch, privileged,
qemu: Use FW descriptors to report FW image paths Now that we have qemuFirmwareGetSupported() so that it also returns a list of FW image paths, we can use it to report them in domain capabilities instead of the old time default list. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 09:29:05 +00:00
&autoFirmwares, &secure,
&firmwaresAlt, &nfirmwaresAlt) < 0)
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
return -1;
if (autoFirmwares & (1ULL << VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS))
VIR_DOMAIN_CAPS_ENUM_SET(os->firmware, VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS);
if (autoFirmwares & (1ULL << VIR_DOMAIN_OS_DEF_FIRMWARE_EFI))
VIR_DOMAIN_CAPS_ENUM_SET(os->firmware, VIR_DOMAIN_OS_DEF_FIRMWARE_EFI);
qemu: Use FW descriptors to report FW image paths Now that we have qemuFirmwareGetSupported() so that it also returns a list of FW image paths, we can use it to report them in domain capabilities instead of the old time default list. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 09:29:05 +00:00
if (virQEMUCapsFillDomainLoaderCaps(capsLoader, secure,
firmwaresAlt ? firmwaresAlt : firmwares,
firmwaresAlt ? nfirmwaresAlt : nfirmwares) < 0)
goto cleanup;
ret = 0;
cleanup:
virFirmwareFreeList(firmwaresAlt, nfirmwaresAlt);
return ret;
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: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
static void
qemu: cache host arch separately from virCapsPtr As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 17:51:22 +00:00
virQEMUCapsFillDomainCPUCaps(virQEMUCapsPtr qemuCaps,
virArch hostarch,
qemu: Fill in CPU domain capabilities Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-22 20:22:30 +00:00
virDomainCapsPtr domCaps)
{
qemu: cache host arch separately from virCapsPtr As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 17:51:22 +00:00
if (virQEMUCapsIsCPUModeSupported(qemuCaps, hostarch, domCaps->virttype,
qemu: Pass machine type to virQEMUCapsIsCPUModeSupported The usability of a specific CPU mode may depend on machine type, let's prepare for this by passing it to virQEMUCapsIsCPUModeSupported. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-02-05 14:51:09 +00:00
VIR_CPU_MODE_HOST_PASSTHROUGH,
qemu: Advertise migratable attribute for CPU in domcaps Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-02 22:28:10 +00:00
domCaps->machine)) {
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: Advertise migratable attribute for CPU in domcaps Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-02 22:28:10 +00:00
domCaps->cpu.hostPassthroughMigratable.report = true;
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_MIGRATABLE)) {
VIR_DOMAIN_CAPS_ENUM_SET(domCaps->cpu.hostPassthroughMigratable,
VIR_TRISTATE_SWITCH_ON);
}
VIR_DOMAIN_CAPS_ENUM_SET(domCaps->cpu.hostPassthroughMigratable,
VIR_TRISTATE_SWITCH_OFF);
}
qemu: wire up support for maximum CPU model The "max" model can be treated the same way as "host" model in general. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-05 18:35:10 +00:00
if (virQEMUCapsIsCPUModeSupported(qemuCaps, hostarch, domCaps->virttype,
VIR_CPU_MODE_MAXIMUM,
domCaps->machine)) {
domCaps->cpu.maximum = true;
domCaps->cpu.maximumMigratable.report = true;
VIR_DOMAIN_CAPS_ENUM_SET(domCaps->cpu.maximumMigratable,
VIR_TRISTATE_SWITCH_ON);
VIR_DOMAIN_CAPS_ENUM_SET(domCaps->cpu.maximumMigratable,
VIR_TRISTATE_SWITCH_OFF);
}
qemu: cache host arch separately from virCapsPtr As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 17:51:22 +00:00
if (virQEMUCapsIsCPUModeSupported(qemuCaps, hostarch, domCaps->virttype,
qemu: Pass machine type to virQEMUCapsIsCPUModeSupported The usability of a specific CPU mode may depend on machine type, let's prepare for this by passing it to virQEMUCapsIsCPUModeSupported. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-02-05 14:51:09 +00:00
VIR_CPU_MODE_HOST_MODEL,
domCaps->machine)) {
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
qemu: cache host arch separately from virCapsPtr As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 17:51:22 +00:00
if (virQEMUCapsIsCPUModeSupported(qemuCaps, hostarch, domCaps->virttype,
qemu: Pass machine type to virQEMUCapsIsCPUModeSupported The usability of a specific CPU mode may depend on machine type, let's prepare for this by passing it to virQEMUCapsIsCPUModeSupported. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-02-05 14:51:09 +00:00
VIR_CPU_MODE_CUSTOM,
domCaps->machine)) {
qemu: remove use of the terms 'whitelist' and 'blacklist' from CPU code When listing CPU models, we need to filter the data based on sets of permitted and forbidden CPU models. Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-16 10:16:43 +00:00
const char *forbidden[] = { "host", NULL };
lib: Replace VIR_AUTOSTRINGLIST with GStrv Glib provides g_auto(GStrv) which is in-place replacement of our VIR_AUTOSTRINGLIST. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-12-01 08:21:32 +00:00
g_auto(GStrv) models = 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: Rename virQEMUCaps{Get,Fetch}CPUDefinitions The functions return virDomainCapsCPUModelsPtr and thus they should be called *CPUModels for consistency. Functions called *CPUDefinitions will work on qemuMonitorCPUDefsPtr. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-09 08:14:59 +00:00
domCaps->cpu.custom = virQEMUCapsGetCPUModels(qemuCaps,
domCaps->virttype,
(const char **)models,
qemu: remove use of the terms 'whitelist' and 'blacklist' from CPU code When listing CPU models, we need to filter the data based on sets of permitted and forbidden CPU models. Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-16 10:16:43 +00:00
forbidden);
qemu: Use virQEMUCapsGetCPUDefinitions more Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-20 20:54:13 +00:00
} else {
domCaps->cpu.custom = NULL;
qemu: Introduce virQEMUCapsIsCPUModeSupported Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-08-03 14:22:30 +00:00
}
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
}
qemu: domcaps: Simplify adding new domaincaps based on qemu caps Add a helper which converts qemu emulator capabilities to the domain capability XML. This will simplify future additions of new features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-30 15:40:03 +00:00
struct virQEMUCapsDomainFeatureCapabilityTuple {
virDomainCapsFeature domcap;
virQEMUCapsFlags qemucap;
};
/**
* This maps the qemu features to the entries in <features> of the domain
* capability XML.
* */
static const struct virQEMUCapsDomainFeatureCapabilityTuple domCapsTuples[] = {
{ VIR_DOMAIN_CAPS_FEATURE_IOTHREADS, QEMU_CAPS_OBJECT_IOTHREAD },
{ VIR_DOMAIN_CAPS_FEATURE_VMCOREINFO, QEMU_CAPS_DEVICE_VMCOREINFO },
{ VIR_DOMAIN_CAPS_FEATURE_GENID, QEMU_CAPS_DEVICE_VMGENID },
qemu: caps: Base support of 'backingStoreInput' domain feature on QEMU_CAPS_BLOCKDEV The qemu driver will obey <backingStore> when we support blockdev. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-18 15:56:51 +00:00
{ VIR_DOMAIN_CAPS_FEATURE_BACKING_STORE_INPUT, QEMU_CAPS_BLOCKDEV },
qemu: Add support for VIR_DOMAIN_CAPS_FEATURE_BACKUP Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-12-03 16:38:13 +00:00
{ VIR_DOMAIN_CAPS_FEATURE_BACKUP, QEMU_CAPS_INCREMENTAL_BACKUP },
qemu: domcaps: Simplify adding new domaincaps based on qemu caps Add a helper which converts qemu emulator capabilities to the domain capability XML. This will simplify future additions of new features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-30 15:40:03 +00:00
};
qemu: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
static void
qemu: domcaps: Simplify adding new domaincaps based on qemu caps Add a helper which converts qemu emulator capabilities to the domain capability XML. This will simplify future additions of new features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-30 15:40:03 +00:00
virQEMUCapsFillDomainFeaturesFromQEMUCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsPtr domCaps)
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
{
qemu: domcaps: Simplify adding new domaincaps based on qemu caps Add a helper which converts qemu emulator capabilities to the domain capability XML. This will simplify future additions of new features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-30 15:40:03 +00:00
size_t i;
for (i = 0; i < G_N_ELEMENTS(domCapsTuples); i++) {
if (virQEMUCapsGet(qemuCaps, domCapsTuples[i].qemucap))
domCaps->features[domCapsTuples[i].domcap] = VIR_TRISTATE_BOOL_YES;
domcaps: Remove function initializing domain caps as unsupported Commit 5751a0b6b1968bb2354b2ac21cc5938b93009590 added a helper function called virDomainCapsFeaturesInitUnsupported which initialized all domain capability features as unsupported. When adding a new feature this would initialize it as unsupported also for hypervisor drivers which the original author possibly didn't intend to modify. To prevent accidental wrong value being reported in such case revert back to initializing individual features in the hypervisor drivers themselves. This is not a straight revert as additonal patches modified how we store the capabilities. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-11-21 08:52:24 +00:00
else
domCaps->features[domCapsTuples[i].domcap] = VIR_TRISTATE_BOOL_NO;
qemu: domcaps: Simplify adding new domaincaps based on qemu caps Add a helper which converts qemu emulator capabilities to the domain capability XML. This will simplify future additions of new features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-30 15:40:03 +00:00
}
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
}
qemu: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
static void
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: domcaps: use virTristateBool for 'supported' Switch most 'supported' handling to use virTristateBool, so eventually we can handle the ABSENT state. For now the XML formatter treats ABSENT the same as FALSE, so there's no functional output change. This will be addressed in later patches Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-08 23:03:20 +00:00
disk->supported = VIR_TRISTATE_BOOL_YES;
qemu: fill in virCapsEnum 'report' Set report=true for all enums currently formatted in the XML Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-06 23:21:45 +00:00
disk->diskDevice.report = true;
disk->bus.report = true;
disk->model.report = 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: Remove redundant condition No need to check whether we're dealing with a pSeries guest twice within just a few lines. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-11-28 15:34:41 +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: Remove redundant condition No need to check whether we're dealing with a pSeries guest twice within just a few lines. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-11-28 15:34:41 +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
qemu: Add arch parameter to qemuDomainMachine*() We want the signatures to be consistent, and also we're going to start using the additional parameter next. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-11-28 15:48:41 +00:00
if (qemuDomainMachineHasBuiltinIDE(machine, qemuCaps->arch))
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
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 */);
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: domcaps: Report disk <enum name="model"> This generates new XML like: <disk> <enum name='model'> <value>virtio</value> <value>virtio-transitional</value> <value>virtio-non-transitional</value> </enum> </disk> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-20 19:18:40 +00:00
/* disk->model values */
VIR_DOMAIN_CAPS_ENUM_SET(disk->model, VIR_DOMAIN_DISK_MODEL_VIRTIO);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL)) {
VIR_DOMAIN_CAPS_ENUM_SET(disk->model,
VIR_DOMAIN_DISK_MODEL_VIRTIO_TRANSITIONAL);
VIR_DOMAIN_CAPS_ENUM_SET(disk->model,
VIR_DOMAIN_DISK_MODEL_VIRTIO_NON_TRANSITIONAL);
}
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_validate: Deduplicate code for graphics type check Similarly to previous commits, we can utilize domCaps to check if graphics type is supported. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2020-11-17 10:00:31 +00:00
void
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
virQEMUCapsFillDomainDeviceGraphicsCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsDeviceGraphicsPtr dev)
{
conf: domcaps: use virTristateBool for 'supported' Switch most 'supported' handling to use virTristateBool, so eventually we can handle the ABSENT state. For now the XML formatter treats ABSENT the same as FALSE, so there's no functional output change. This will be addressed in later patches Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-08 23:03:20 +00:00
dev->supported = VIR_TRISTATE_BOOL_YES;
qemu: fill in virCapsEnum 'report' Set report=true for all enums currently formatted in the XML Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-06 23:21:45 +00:00
dev->type.report = true;
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
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);
domcaps: Report egl-headless graphics type QEMU supports egl-headless if QEMU_CAPS_EGL_HEADLESS capability is present. There are some additional requirements but those are checked for in qemuValidateDomainDeviceDefGraphics() and depend on domain configuration and thus are not representable in domain capabilities. Let's stick with plain qemuCaps check then. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2020-11-17 10:00:26 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_EGL_HEADLESS))
VIR_DOMAIN_CAPS_ENUM_SET(dev->type, VIR_DOMAIN_GRAPHICS_TYPE_EGL_HEADLESS);
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
}
qemu_validate: Deduplicate code for video model check In my recent commit of a33279daa8 I've moved video model check from domain capabilities validator into qemu validator. During that I had to basically duplicate video model to qemuCaps checks. Problem with this approach is that after my commit qemu validator and domCaps are disconnected and thus domCaps might report (in general) different set of supported video models. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2020-11-17 09:26:14 +00:00
void
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(virQEMUCapsPtr qemuCaps,
virDomainCapsDeviceVideoPtr dev)
{
conf: domcaps: use virTristateBool for 'supported' Switch most 'supported' handling to use virTristateBool, so eventually we can handle the ABSENT state. For now the XML formatter treats ABSENT the same as FALSE, so there's no functional output change. This will be addressed in later patches Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-08 23:03:20 +00:00
dev->supported = VIR_TRISTATE_BOOL_YES;
qemu: fill in virCapsEnum 'report' Set report=true for all enums currently formatted in the XML Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-06 23:21:45 +00:00
dev->modelType.report = true;
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
qemu: set domain capability for video type "none" In a follow-up commit, we will use the domain capabilities to validate video device configurations, which means that we also need to make sure that the domain capabilities include the "none" video device. Reviewed-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
2019-10-18 15:30:13 +00:00
VIR_DOMAIN_CAPS_ENUM_SET(dev->modelType, VIR_DOMAIN_VIDEO_TYPE_NONE);
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
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);
qemu: capabilities: Fill in bochs-display info 086c19d69 added bochs-display capability but didn't fill in the info for domain capabilities. Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-03 13:28:40 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_BOCHS_DISPLAY))
VIR_DOMAIN_CAPS_ENUM_SET(dev->modelType, VIR_DOMAIN_VIDEO_TYPE_BOCHS);
qemu: set domain capability for ramfb device commit 9bfcf0f62d9cf16db526a948242a7409ae883209 added the QEMU_CAPS_DEVICE_RAMFB capability but did not set the domain capability. This patch sets the domain capability for the ramfb device and updates the tests. Reviewed-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
2019-10-18 15:30:12 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_RAMFB))
VIR_DOMAIN_CAPS_ENUM_SET(dev->modelType, VIR_DOMAIN_VIDEO_TYPE_RAMFB);
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
}
qemu: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
static void
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 supportsPassthroughVFIO = qemuHostdevHostSupportsPassthroughVFIO();
conf: domcaps: use virTristateBool for 'supported' Switch most 'supported' handling to use virTristateBool, so eventually we can handle the ABSENT state. For now the XML formatter treats ABSENT the same as FALSE, so there's no functional output change. This will be addressed in later patches Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-08 23:03:20 +00:00
hostdev->supported = VIR_TRISTATE_BOOL_YES;
qemu: fill in virCapsEnum 'report' Set report=true for all enums currently formatted in the XML Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-06 23:21:45 +00:00
hostdev->mode.report = true;
hostdev->startupPolicy.report = true;
hostdev->subsysType.report = true;
hostdev->capsType.report = true;
hostdev->pciBackend.report = 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,
qemu: Drop QEMU_CAPS_DEVICE_SCSI_GENERIC It was already available in 1.5.0, so we can assume it's present and avoid checking for it at runtime. This commit is best viewed with 'git show -w'. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-09-18 10:29:10 +00:00
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI,
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI);
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: Do not report USB as subsystem type if it is not available libvirt currently always reports that USB is available as a bus subsystem type when running "virsh domcapabilities". However, this is not always true, for example the qemu-system-s390x binary normally never has support for USB. Thus we should only report that USB is available if there is also a USB host controller available where we can attach USB devices. Reported-by: Sebastian Mitterle <smitterl@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1759849 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-13 08:04:57 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_PIIX3_USB_UHCI) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_PIIX4_USB_UHCI) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_USB_EHCI) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_ICH9_USB_EHCI1) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_VT82C686B_USB_UHCI) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_PCI_OHCI) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_NEC_USB_XHCI) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_QEMU_XHCI)) {
VIR_DOMAIN_CAPS_ENUM_SET(hostdev->subsysType,
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB);
}
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
/* 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);
}
}
qemu_validate: Deduplicate code for RNG model check In my recent commit of 5216304bfe I've moved RNG model check from domain capabilities validator into qemu validator. During that I had to basically duplicate RNG model to qemuCaps checks. Problem with this approach is that after my commit qemu validator and domCaps are disconnected and thus domCaps might report (in general) different set of supported RNG models. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2020-11-17 09:37:10 +00:00
void
qemu: capabilities: fill in domcaps <rng> The model logic is taken from qemuDomainRNGDefValidate Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-31 21:19:40 +00:00
virQEMUCapsFillDomainDeviceRNGCaps(virQEMUCapsPtr qemuCaps,
virDomainCapsDeviceRNGPtr rng)
{
rng->supported = VIR_TRISTATE_BOOL_YES;
rng->model.report = true;
rng->backendModel.report = true;
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_RNG)) {
VIR_DOMAIN_CAPS_ENUM_SET(rng->model, VIR_DOMAIN_RNG_MODEL_VIRTIO);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL) ||
virQEMUCapsGet(qemuCaps, QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY)) {
VIR_DOMAIN_CAPS_ENUM_SET(rng->model,
VIR_DOMAIN_RNG_MODEL_VIRTIO_TRANSITIONAL,
VIR_DOMAIN_RNG_MODEL_VIRTIO_NON_TRANSITIONAL);
}
}
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_RNG_EGD))
VIR_DOMAIN_CAPS_ENUM_SET(rng->backendModel, VIR_DOMAIN_RNG_BACKEND_EGD);
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_RNG_RANDOM))
VIR_DOMAIN_CAPS_ENUM_SET(rng->backendModel, VIR_DOMAIN_RNG_BACKEND_RANDOM);
qemu: Implement builtin rng backend Since v4.2-rc0, QEMU introduced a builtin rng backend that uses getrandom() syscall to generate random. Add it to libvirt with the backend model 'builtin'. https://bugzilla.redhat.com/show_bug.cgi?id=1785091 Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-09 08:00:08 +00:00
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_RNG_BUILTIN))
VIR_DOMAIN_CAPS_ENUM_SET(rng->backendModel, VIR_DOMAIN_RNG_BACKEND_BUILTIN);
qemu: capabilities: fill in domcaps <rng> The model logic is taken from qemuDomainRNGDefValidate Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-31 21:19:40 +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.
*/
qemu: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
static void
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(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: domcaps: fill in explicit supported BOOL_NO Only gic->supported needs an explicit BOOL_NO setting, all other 'supported' values are handling things correctly Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-19 19:15:06 +00:00
gic->supported = VIR_TRISTATE_BOOL_NO;
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: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
return;
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: 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;
conf: domcaps: use virTristateBool for 'supported' Switch most 'supported' handling to use virTristateBool, so eventually we can handle the ABSENT state. For now the XML formatter treats ABSENT the same as FALSE, so there's no functional output change. This will be addressed in later patches Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-02-08 23:03:20 +00:00
gic->supported = VIR_TRISTATE_BOOL_YES;
qemu: fill in virCapsEnum 'report' Set report=true for all enums currently formatted in the XML Acked-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-06 23:21:45 +00:00
gic->version.report = true;
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
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
}
}
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.
*/
qemu: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
static void
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(virQEMUCapsPtr qemuCaps,
virDomainCapsPtr domCaps)
{
virSEVCapability *cap = qemuCaps->sevCapabilities;
if (!cap)
qemu: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
return;
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: caps: Rework memory allocation in virQEMUCapsFillDomainFeatureSEVCaps Use g_new0 instead of VIR_ALLOC to avoid error cases. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:18:55 +00:00
domCaps->sev = g_new0(virSEVCapability, 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: caps: Rework memory allocation in virQEMUCapsFillDomainFeatureSEVCaps Use g_new0 instead of VIR_ALLOC to avoid error cases. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:18:55 +00:00
domCaps->sev->pdh = g_strdup(cap->pdh);
domCaps->sev->cert_chain = g_strdup(cap->cert_chain);
domCaps->sev->cbitpos = cap->cbitpos;
domCaps->sev->reduced_phys_bits = cap->reduced_phys_bits;
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: cache host arch separately from virCapsPtr As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 17:51:22 +00:00
virQEMUCapsFillDomainCaps(virQEMUCapsPtr qemuCaps,
virArch hostarch,
qemu: Fill in CPU domain capabilities Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-04-22 20:22:30 +00:00
virDomainCapsPtr domCaps,
domain capabilities: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
bool privileged,
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: capabilities: fill in domcaps <rng> The model logic is taken from qemuDomainRNGDefValidate Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2019-03-31 21:19:40 +00:00
virDomainCapsDeviceRNGPtr rng = &domCaps->rng;
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: domcaps: Simplify adding new domaincaps based on qemu caps Add a helper which converts qemu emulator capabilities to the domain capability XML. This will simplify future additions of new features. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-30 15:40:03 +00:00
virQEMUCapsFillDomainFeaturesFromQEMUCaps(qemuCaps, domCaps);
qemu: domcaps: Initialize all features While the qemu driver currently implements all domain capability features, we should initialize all features using the helper similarly to how we do it in drivers which don't support any. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-13 15:32:21 +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,
qemu: Pass virDomainVirtType to APIs dealing with machine types Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-10-24 06:52:21 +00:00
domCaps->virttype,
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->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: Expose firmware auto selection feature If a management application wants to use firmware auto selection feature it can't currently know if the libvirtd it's talking to support is or not. Moreover, it doesn't know which values that are accepted for the @firmware attribute of <os/> when parsing will allow successful start of the domain later, i.e. if the mgmt application wants to use 'bios' whether there exists a FW descriptor in the system that describes bios. This commit then adds 'firmware' enum to <os/> element in <domainCapabilities/> XML like this: <enum name='firmware'> <value>bios</value> <value>efi</value> </enum> We can see both 'bios' and 'efi' listed which means that there are descriptors for both found in the system (matched with the machine type and architecture reported in the domain capabilities earlier and not shown here). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 10:42:14 +00:00
if (virQEMUCapsFillDomainOSCaps(os,
domCaps->machine,
domCaps->arch,
privileged,
qemu: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
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;
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: cache host arch separately from virCapsPtr As part of a goal to eliminate the need to use virCapsPtr for anything other than the virConnectGetCapabilies() API impl, cache the host arch against the QEMU driver struct and use that field directly. In the tests we move virArchFromHost() globally in testutils.c so that every test runs with a fixed default architecture reported. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-26 17:51:22 +00:00
virQEMUCapsFillDomainCPUCaps(qemuCaps, hostarch, domCaps);
qemu: caps: Make capability filler functions void Most of them don't have anything to report so we can simplify the logic. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-25 11:25:20 +00:00
virQEMUCapsFillDomainDeviceDiskCaps(qemuCaps, domCaps->machine, disk);
virQEMUCapsFillDomainDeviceGraphicsCaps(qemuCaps, graphics);
virQEMUCapsFillDomainDeviceVideoCaps(qemuCaps, video);
virQEMUCapsFillDomainDeviceHostdevCaps(qemuCaps, hostdev);
virQEMUCapsFillDomainDeviceRNGCaps(qemuCaps, rng);
virQEMUCapsFillDomainFeatureGICCaps(qemuCaps, domCaps);
virQEMUCapsFillDomainFeatureSEVCaps(qemuCaps, domCaps);
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
qemu: capabilities: Extract code from virQEMUCapsStripMachineAliases Separate out the internals as they will become more complex soon. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:11:08 +00:00
static void
virQEMUCapsStripMachineAliasesForVirtType(virQEMUCapsPtr qemuCaps,
virDomainVirtType virtType)
{
virQEMUCapsAccelPtr accel = virQEMUCapsGetAccel(qemuCaps, virtType);
size_t i;
for (i = 0; i < accel->nmachineTypes; i++) {
virQEMUCapsMachineTypePtr mach = &accel->machineTypes[i];
qemu: capabilities: Replace aliased machine type by copy of the canonical machine The previous approac of just purging the alias combined with the fact that we filled in fake machine types in the test data meant that if a test case used an alias machine type such as 'pc' or 'q35' it would not properly resolve to the actual data returned by qemu. This started to be a problem since the CPU driver now looks at the default CPU reported with the machine type. This patch replaces the original approach of just removing the alias by replacing it with a copy of the machine type data which the type would alias to. This means that we are using the real data while we don't modify the test output after every qemu upgrade. Additionally this change will allow us to drop adding the fake machine types later. The test fallout is from actually excercising the CPU driver with actual data. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:20:25 +00:00
g_autofree char *name = g_steal_pointer(&mach->alias);
qemu: capabilities: Extract code from virQEMUCapsStripMachineAliases Separate out the internals as they will become more complex soon. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:11:08 +00:00
qemu: capabilities: Replace aliased machine type by copy of the canonical machine The previous approac of just purging the alias combined with the fact that we filled in fake machine types in the test data meant that if a test case used an alias machine type such as 'pc' or 'q35' it would not properly resolve to the actual data returned by qemu. This started to be a problem since the CPU driver now looks at the default CPU reported with the machine type. This patch replaces the original approach of just removing the alias by replacing it with a copy of the machine type data which the type would alias to. This means that we are using the real data while we don't modify the test output after every qemu upgrade. Additionally this change will allow us to drop adding the fake machine types later. The test fallout is from actually excercising the CPU driver with actual data. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:20:25 +00:00
if (name) {
virQEMUCapsAddMachine(qemuCaps, virtType, name, NULL, mach->defaultCPU,
qemu: Track numa-mem-supported machine attribute There is 'numa-mem-supported' machine attribute which specifies whether '-numa mem=' is supported. Store it in our capabilities as it will be used in later commits when building the command line. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-14 11:11:01 +00:00
mach->maxCpus, mach->hotplugCpus, mach->qemuDefault,
qemu: report whether a machine type is deprecated in capabilities QEMU has the ability to mark machine types as deprecated. This should be exposed to management applications in the capabilities. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-22 12:16:23 +00:00
mach->numaMemSupported, mach->defaultRAMid,
mach->deprecated);
qemu: capabilities: Replace aliased machine type by copy of the canonical machine The previous approac of just purging the alias combined with the fact that we filled in fake machine types in the test data meant that if a test case used an alias machine type such as 'pc' or 'q35' it would not properly resolve to the actual data returned by qemu. This started to be a problem since the CPU driver now looks at the default CPU reported with the machine type. This patch replaces the original approach of just removing the alias by replacing it with a copy of the machine type data which the type would alias to. This means that we are using the real data while we don't modify the test output after every qemu upgrade. Additionally this change will allow us to drop adding the fake machine types later. The test fallout is from actually excercising the CPU driver with actual data. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:20:25 +00:00
}
qemu: capabilities: Extract code from virQEMUCapsStripMachineAliases Separate out the internals as they will become more complex soon. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:11:08 +00:00
}
}
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
*
qemu: capabilities: Replace aliased machine type by copy of the canonical machine The previous approac of just purging the alias combined with the fact that we filled in fake machine types in the test data meant that if a test case used an alias machine type such as 'pc' or 'q35' it would not properly resolve to the actual data returned by qemu. This started to be a problem since the CPU driver now looks at the default CPU reported with the machine type. This patch replaces the original approach of just removing the alias by replacing it with a copy of the machine type data which the type would alias to. This means that we are using the real data while we don't modify the test output after every qemu upgrade. Additionally this change will allow us to drop adding the fake machine types later. The test fallout is from actually excercising the CPU driver with actual data. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:20:25 +00:00
* Replace all aliases by the copy of the machine type they point to without
* actually having to modify the name. This allows us to add tests with the
* aliased machine without having to change the output files all the time.
*
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
* 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)
{
qemu: capabilities: Extract code from virQEMUCapsStripMachineAliases Separate out the internals as they will become more complex soon. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-23 12:11:08 +00:00
virQEMUCapsStripMachineAliasesForVirtType(qemuCaps, VIR_DOMAIN_VIRT_KVM);
virQEMUCapsStripMachineAliasesForVirtType(qemuCaps, VIR_DOMAIN_VIRT_QEMU);
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
}
Reference in New Issue Copy Permalink