To support virtio-blk queue-size option, this commit adds capability
detection to the option.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
They are no longer used as we now assume that all tuning caps are
present and in case some will be removed we'll need to use different
probing methods.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
egl-headless graphics can be compiled out in qemu so we need to be able
to know whether the given qemu version support it.
Base the capability on the presence of the 'egl-headless' member in
'query-display-options' or imply it if 'query-display-options' is not
supported as we implied it before for all versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
SDL graphics can be compiled out in qemu so we need to be able to know
whether the given qemu version support it.
Base the capability on the presence of the 'sdl' member in
'query-display-options' or imply it if 'query-display-options' is not
supported as we implied it before for all versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
The feature is present in all supported qemu versions (>2.11) and there
isn't a reasonable way to detect it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is present in all supported qemu versions (>2.11) and there
isn't a reasonable way to detect it.
In addition the capability wasn't even used to gate any functionality
except for reporting the presence in the domain capabilities XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is present in all supported qemu versions (>2.11) and there
isn't a reasonable way to detect it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is present in all supported qemu versions (>2.11) and there
isn't a reasonable way to detect it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is present in all supported QEMU versions and there isn't a
more elegant way to detect it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All supported qemus have it, there isn't an elegant way to detect it and
it's unlikely to be ever removed on purpose.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
'query-commandline-options' never returned 'vmport' but we can detect it
in the list of supported object types. This removes it from all non-x86
originating test data as it's platform specific.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All supported qemu versions have 'query-qmp-schema' so we can remove the
check whether it exists and all logic conntected to it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move it under AARCH 64, since it's a platform specific feature, thus it
will be removed from all other platforms.
Since virQEMUCapsInitQMPBasicArch is used in qemuxml2argv test to
initiate qemuCaps for tests with fake capabilities, all the tests gain
GIC support now.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Right now we're passing a "base" string that contains both,
separated by an underscore. Some changes that we're going to
introduce later will require us to have the version number on its
own, and instead of delegating the task of splitting the two apart
to the callback it make more sense to perform it upfront.
This change results in quite a bit of churn because we're now
using the version number only, without the prefix, to calculate
the dummy microcodeVersion.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
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>
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>
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>
The '-realtime mlock' cmd line argument was introduced in QEMU
commit v1.5.0-rc0~190 which matches minimal QEMU version we
require. Therefore, the capability will always be present.
Apparently, nearly none of our xml2argv test cases had the
capability hence slightly bigger change under qemuxml2argvdata/.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'blockdev-snapshot-sync' is present in QEMU since v0.14.0-rc0 and
'transaction' since v1.1.0 (52e7c241ac766406f05fa)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu added the 'drive-mirror' command in v1.3.0 (d9b902db3fb71fdc)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu added the 'block-commit' command in v1.3.0 (ed61fc10e8c8d2)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This was detected by the presence of 'block-stream' which is present in
qemu since v1.1 (db58f9c0605fa151b8c4)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since commit a7424faff QMP is always used.
Also, commit 932534e8 removed the last use of this apart from:
* parsing/formatting this in the caps cache
* using it as a temporary variable to know when to report an error
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
