We require QEMU >= 1.5.0, assume every QEMU supports it.
Sadly that does not let us trivially drop qemuMonitor's
priv->monJSON bool, because of qemuDomainQemuAttach.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This makes qemuDomainSupportsNetdev identical to
qemuDomainSupportsNicdev and leaves some code in
qemuDomainAttachNetDevice to be cleaned up later.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Supported since QEMU 0.13, but we require QEMU 1.5.0.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This capability will be set when the pcie-pci-bridge device
is available in the QEMU binary.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The QEMU binary is compiled from the v2.12.0-rc0 tag.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Commit 4ae59411 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: NAndrea Bolognani <abologna@redhat.com>

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.

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: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

query-cpu-definitions QMP command returns a list of unavailable features
which prevent CPU models from being usable on the current host. So far
we only checked whether the list was empty to mark CPU models as
(un)usable. This patch parses all unavailable features for each CPU
model and stores them in virDomainCapsCPUModel as a list of usability
blockers.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

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: NJohn Ferlan <jferlan@redhat.com>

For reference, these were generated by updating a local qemu git
repository to the latest upstream, making sure the latest dependencies
were met via "dnf builddep qemu" from my sufficiently privileged root
account, checking out the v2.10.0 tag, and building in order to generate
an "x86_64-softmmu/qemu-system-x86_64" image.

Then using a clean libvirt tree updated to master and built, the image
was then provided as input:

    tests/qemucapsprobe /path/to/x86_64-softmmu/qemu-system-x86_64 > \
       tests/qemucapabilitiesdata/caps_2.10.0.x86_64.replies

With the .replies file in place and the DO_TEST line added and build,
then running the following commands:

    touch tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
    VIR_TEST_REGENERATE_OUTPUT=1 ./tests/qemucapabilitiestest

to generate tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml and both
were added to the commit.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.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>

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>

Format iommu_platform= and ats= for virtio devices.

https://bugzilla.redhat.com/show_bug.cgi?id=1283251Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Format the device-iotlb attribute.

https://bugzilla.redhat.com/show_bug.cgi?id=1283251Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This option turns on extended interrupt mode,
which allows more than 255 vCPUs.

https://bugzilla.redhat.com/show_bug.cgi?id=1451282Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

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

https://bugzilla.redhat.com/show_bug.cgi?id=1427005

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

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Acked-by: NAndrea Bolognani <abologna@redhat.com>

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

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

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

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

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

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.

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

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

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

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.

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

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