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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

It was already available in 1.5.0.

Moreover, we're not even formatting it on the QEMU command
line, ever: we just use it as part of some logic that decides
whether KVM support should be advertised, and as it turns out
that logic is actually buggy and dropping this capability
fixes it.

https://bugzilla.redhat.com/show_bug.cgi?id=1628469Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The capability was introduced in QEMU 1.5.0, which is our
minimum supported QEMU version these days.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The capability was introduced in QEMU 1.3.1 and we require
QEMU 1.5.0 these days.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Introduced by QEMU commit 28b77657 in v1.0-rc4~21^2~8.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Introduced by QEMU commit c29029d which was included in 1.5.0
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Added by QEMU commit 65bb3a5 contained in v1.1.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Added by QEMU commit 65bb3a5 contained in v1.1.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the bootindex argument was already supported.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the configfd argument was already supported.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Added by commit fc66c160 and not used since.

Also, the device was present in QEMU 1.5.0 so this capability
will not be needed if we ever decide to implement usb-net support.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Historically the argv -> xml convertor wanted the same default machine
as we'd set when parsing xml. The latter has now changed, however, to
use a default defined by libvirt. The former needs fixing to again
honour the default QEMU machine.

This exposed a bug in handling for the aarch64 target, as QEMU does not
define any default machine. Thus we should not having been accepting
argv without a -machine provided.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

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: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The capability was usable since qemu 1.3 so we can remove all the
detection code.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The capability currently is not enabled so that we can add individual
bits first.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The capability was never set except for (stale) tests. Remove it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The field was added in qemu v0.13.0-rc0-731-g1ca4d09ae0 so all supported
qemu versions now use it.

There's a LOT of test fallout as we did not use capabilities close
enough to upstream for many of our tests.

Several tests had a 'bootindex' variant. Since they'd become redundant
they are also removed here.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

QEMU 2.12 introduced a new vfio-pci device option 'display=on/off/auto'.
This patch introduces the necessary capability.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

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: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Support for specifying it with the -device frontend was added recently.
Add a capability for it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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: NBrijesh Singh <brijesh.singh@amd.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We are still hoping all of such checks will be moved there and this is one small
step in that direction.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Extend the QEMU capabilities with tpm-emulator support.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

QEMU >= 2.12 will support passing of pre-opened file descriptors for
socket based character devices.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Add a new capability flag for vhost-vsock-device

https://bugzilla.redhat.com/show_bug.cgi?id=1291851Signed-off-by: NJán Tomko <jtomko@redhat.com>

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: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>

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: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Add the query of the device objects for the vmgenid device
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
ACKed-by: NMichal Privoznik <mprivozn@redhat.com>

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: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NFilip Alac <filipalac@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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: NMichal Privoznik <mprivozn@redhat.com>

Support OpenGL acceleration capability when using SDL graphics.
Signed-off-by: NMaciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This capability tracks if memory-backend-file has discard-data
attribute or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>