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: NJiri Denemark <jdenemar@redhat.com>

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: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

All serial devices shoule have an associated capability.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

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.

'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.

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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The architecture itself is called ppc64, and it can run both in big
endian and little endian mode - the latter is known as ppc64le.

From the (virtual) hardware point of view, ppc64 is a more accurate
name so it should be used here.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NLin Ma <lma@suse.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The patch adds a capability for spapr-pci-host-bridge.numa_node.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This new capability can be used to detect whether a QEMU
binary supports the spapr-pci-host-bridge controller.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Every qemu version we support has QEMU_CAPS_CHARDEV, so stop
explicitly tracking it and blacklist it like we've done for many
other feature flags.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

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

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.

This unbreaks emulators that don't support this command such as
qemu-system-mips*.

Reference: http://bugs.debian.org/854125

Add the capability to detect if the qemu binary can support the feature
to use throttling.group.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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: NJiri Denemark <jdenemar@redhat.com>

Do all the stuff for the vhost-scsi capability in QEMU,
so it's in place for our checks later.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

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.

Sync up to the released version of qemu.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Add the capability to detect if the qemu binary can support the feature
to use bps-max-length and friends.

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: NPavel Hrdina <phrdina@redhat.com>

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: NPavel Hrdina <phrdina@redhat.com>

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

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

Support for SMP topology was added by qemu commit dc6b1c09849484fbbc50
prior to 0.12.0, our minimum supported qemu version.

$ git describe --tags dc6b1c09849484fbbc50803307e4c7a3d81eab62
v0.11.0-rc0-449-gdc6b1c0
$ git describe --tags --contains dc6b1c09849484fbbc50803307e4c7a3d81eab
v0.12.0-rc0~1477

Add a new capability for the -display command line option, which has
been present since QEMU 1.0.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Add the capability flag and checks for the qemu object 'tls-creds-x509'
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We support qemu version 0.12.0+, which has it.

We have been assuming its support if qemu supports -device,
which all the supported versions do.

The only QEMU versions that don't have such capability are <0.11,
which we no longer support anyway

The only QEMU versions that don't have such capability are <0.11,
which we no longer support anyway

-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