Based on upstream commit 3e08b2b9cb64. This version already dropped the
pre-historic machine types and supports only machine types starting from
'pc-1.0'.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

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

The data is captured from qemu v4.2.0-rc2-19-g2061735ff0
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

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

Add capabilities test data for upcoming qemu 4.2.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Update the capabilities from a non-upstream version (9c70209b63 is not
in qemu.git) to qemu upstream commit 33d6099906 (2019/06/18) so that we
get the QMP schema 'features' field support and are able to detect that
the 'file' block backend supports dynamic auto-read-only.

Note that I've rebuilt this on a machine with a more modern kernel and
microcode which exposes e.g. the recent CPU bug mitigations, thus I
opted to keep the CPU changes rather than trying to do a franken-caps
by updating only the output of query-qmp-schema.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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

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

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

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

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

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

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

Capture and update the 4.0.0 qemu version replies now that it was
released. I opted to keep the CPU differences as there was a qemu bug
which reported an empty string in CPU caps.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Avoid calling the command and fix test fallout.

https://bugzilla.redhat.com/show_bug.cgi?id=1673320Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Based on qemu commit 'v3.1.0-1445-ga61faa3d02'. Will allow checking
for the scsi 'device_id' property.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Since commit a4cda054 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: NPeter Krempa <pkrempa@redhat.com>

Since commit 02e8d0cf 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: NPeter Krempa <pkrempa@redhat.com>

The next release of QEMU is going to be 4.0.0. A bit early, but
this adds capabilities data for x86_64 from current qemu git
15bede554162dda822cd762c689edb6fa32b6e3b
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

This capability tracks if nvdimm has the unarmed attribute or not
for the nvdimm readonly xml attribute.
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

These are based on QEMU v3.1.0-rc2-41-g4822f1ee9e.
Acked-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

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: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Previous commits removed all capabilities from per-device property
probing for:

  pci-assign
  kvm-pci-assign
  usb-host
  scsi-generic

Remove them from the virQEMUCapsDeviceProps list and get rid of the
redundant device-list-properties QMP calls.

Note that 'pci-assign' was already useless, because the QMP version
of the device is called 'kvm-pci-assign', see libvirt commit 72574808
from 2012.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@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>

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

Update for the release of qemu 3.0.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The original capabilities didn't include a patched kernel for spectre,
SPICE gl support and had xen support enabled which we already have
dropped.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Based on qemu commit ab3257c281c1a1a91da1090ac9e38ddd8f860c63
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

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

Use qemuMonitorTestNewFromFileFull which allows to test commands used
along with providing replies. This has two advantages:

1) It's easier to see which command was used when looking at the files
2) We check that the used commands are actually in the correct order
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@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>

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>

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>

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>

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

Signed-off-by: NPavel Hrdina <phrdina@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>

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