The test data for capabilities is obtained from two consecutive qemu
runs when the regular monitor object will be reset. Do the same for the
test monitor object which is not disposed between runs by calling
qemuMonitorResetCommandID.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Use "libvirt not compiled with JSON support" instead of mentioning
yajl specifically.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

According to the policy described on https://libvirt.org/platforms.html
the QEMU versions in the oldest relevant releses are:

  SLES 12: 2.0.0
  RHEL 7: 1.5.3
  Ubuntu 14.04: 2.0.0

Set the minimum to 1.5.0 and drop support for RHEL 6.

This will let us assume lots of capabilities.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

When GIC support was introduced (QEMU 2.6 timeframe) we needed
to make sure both GICv2 hardware and GICv3 hardware were handled
correctly, and that was achieved by having separate capabilities
data for each.

Now that we have capabilities data for several QEMU versions we
can stop storing data for GICv2 and GICv3 hardware separately,
and instead have GICv2 data for QEMU <= 2.10 and GICv3 data for
QEMU >= 2.12, without losing any coverage.
Signed-off-by: NAndrea Bolognani <abologna@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>

Let us introduce the xml and reply files for QEMU 2.11.0 on s390x.
Signed-off-by: NShalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Sometimes we don't regenerate QEMU capabilities replies using QEMU
binary but we simply add a new entry manually.  In that case you need
to manually fix all the replies ids.  This helper will do that for you.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@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>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

Right-aligning backslashes when defining macros or using complex
commands in Makefiles looks cute, but as soon as any changes is
required to the code you end up with either distractingly broken
alignment or unnecessarily big diffs where most of the changes
are just pushing all backslashes a few characters to one side.

Generated using

  $ git grep -El '[[:blank:]][[:blank:]]\\$' | \
    grep -E '*\.([chx]|am|mk)$$' | \
    while read f; do \
      sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \
    done
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Adding s390x qemu caps test for qemu version 2.10.0.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.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: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Cleanups the code a little bit and reduces amount of arguments passed
throughout the functions.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Adjust qemu 2.9 s390 capabilites xml and enable qemu capabilities test.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

We use the "vir" prefix pretty consistently in our
APIs, both external and internal, which made these
macros stood out.

QEMU 2.9.0 is not released yet but it's close to its release and
we need this data to implement new features that will be in
that release.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Expected Qemu replies for versions 2.7 and 2.8 from the s390x
Qemu binary.
Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>

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

CPU related capabilities may differ depending on accelerator used when
probing. Let's use KVM if available when probing QEMU and fall back to
TCG. The created capabilities already contain all we need to distinguish
whether KVM or TCG was used:

    - KVM was used when probing capabilities:
        QEMU_CAPS_KVM is set
        QEMU_CAPS_ENABLE_KVM is not set

    - TCG was used and QEMU supports KVM, but it failed (e.g., missing
      kernel module or wrong /dev/kvm permissions)
        QEMU_CAPS_KVM is not set
        QEMU_CAPS_ENABLE_KVM is set

    - KVM was not used and QEMU does not support it
        QEMU_CAPS_KVM is not set
        QEMU_CAPS_ENABLE_KVM is not set
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Host capabilities provide libvirt's view of the host CPU, but for a
useful support for host-model CPUs we really need a hypervisor's view of
the CPU. And since the view can be differ with emulator, qemu
capabilities is the best place to store the host CPU model.

This patch just copies the CPU model from host capabilities, but this
will change in the future.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Doing a load, copy, format cycle on all QEMU capabilities XML files
should make sure we don't forget to update virQEMUCapsNewCopy when
adding new elements to QEMU capabilities.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

As of (v2.7.0-rc1-52-g42e0d60)

The current version uses the first JSON reply from the file as monitor
greeting. With the new parameter the caller can now request a simple
test monitor to be created, which uses an artificial greeting and uses
all JSON strings from the file as regular replies.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

It's a convenient wrapper around qemuMonitorTestNew which feeds the test
monitor with QMP replies from a specified file.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This function doesn't follow our convention of naming functions.

This function doesn't follow our convention of naming functions.

This function doesn't follow our convention of naming functions.

The qemu-1.6.50 is a beta before the new minor version, let's replace it with
the release qemu-1.7.0.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

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

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

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

Enhance the test to cover all capabilities we probe for rather than
testing the flags only.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In other tests we use "expected" and "actual" to refer to the expected
outcome of the tested API and the result we got, respectively.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Adding new *.replies files for qemucapabilitiestest or updating the
files when libvirt adds an additional QMP command into the probing
process is quite painful. The goal of the new qemucapsprobe command is
to make this process as easy as

    tests/qemucapsprobe /path/to/qemu/binary >caps.replies
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>