1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-12-15 08:24:32 +03:00
Files
libvirt/tests/qemucapabilitiesdata
Peter Krempa e7a7bfa66b qemucapabilitiestest: Add dump for the qemu-10.1 development cycle on x86_64
Data based on 'v10.0.0-1874-gc77283dd5d'.

Notable changes:
 - machine types:
    - added 10.1 machines
    - dropped old machine types up to '4.1' (oldest supported is now '4.2)
 - new devices 'vfio-iommu-user', 'vfio-user-pci'
 - new qom types 'tdx-guest' (including additions to GUEST_CRAS* events
   etc), 'ram-block-attributes'

 - CPU stuff:
    - new models: 'EPYC-Turin-x86_64-cpu',
    - new model versions: 'EPYC-Genoa-v2-x86_64-cpu', 'EPYC-Milan-v3-x86_64-cpu'
                          'EPYC-Rome-v5-x86_64-cpu', 'EPYC-v5-x86_64-cpu'
    - new flags: 'fs-gs-base-ns', 'prefetchi', 'its-no msr-imm'

 - keep-alive options added to all types using 'inet' socket addreses

 - Some platform specific QMP commands are now reported on all
   platforms:
    - 'query-gic-capabilities'
    - 'query-cpu-model-baseline'
    - 'query-cpu-model-comparison',
    - 'dump-skeys'
    - 'set-cpu-topology' (unstable)
    - 'query-s390x-cpu-polarization' and corresponding 'CPU_POLARIZATION_CHANGE' event (unstable)

 - blockdev stuff:
    - blockdev-backup 'on-cbw-error' property added
    - blockdev-mirror 'target-is-zero' property added
    - deprecated commands: 'block-job-complete', 'block-job-dismiss',
                           'block-job-finalize', 'block-job-pause',
                           'block-job-resume'
    - 'dpofua' parameter of scsi disks was now enabled by default

 - 'migrate-extra' flag of 'virtio-net' removed
 - virtio devices gained 'sriov-pf' parameter

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2025-07-08 14:52:31 +02:00
..

=========================
QEMU capabilities testing
=========================

Purpose
=======

Test data in this directory is used:

 - to excercise the capability parsing code in ``qemucapabilitiestest``

 - provides "real" capabilities data for test suites such as ``domaincapstest``
   ``qemuxmlconftest``, and others

 - provides the required data to validate the QMP commands used by libvirt
   against qemu's QMP schema

Naming
======

Files in this directory have the following naming scheme::

  caps_$QEMUVERSION_$ARCHITECTURE.$SUFFIX

or::

  caps_$QEMUVERSION_$ARCHITECTURE+$VARIANT.$SUFFIX

``$QEMUVERSION``

  Numeric representation of the qemu version, e.g.: ``7.0.0``

``$ARCHITECTURE``

  Architecture string such as ``x86_64``, ``aarch64``, etc.

``$SUFFIX``

  ``.replies`` for the dump of the QMP communication used to probe qemu.
  ``.xml`` for the generated capability dump

``$VARIANT``

  The variant name is an optional arbitrary string, not containing any dot.

  A variant is an additional named version of capabilities for given version and
  architecture tuple. This allows for testing special cases which e.g. depend
  on a specific host platform or operating system feature, which differs from
  the main tests. Note that in the test code the variant name is an empty string
  or includes the '+' sign for ease of use.

Known test variants
-------------------

``+hvf``

  Variant of the test data using the Apple OSX Hypervisor Framework acceleration
  for qemu.

``+amdsev``

  Variant of the test data captured on hosts supporting AMD SEV and AMD SEV_ES
  security framework.

Usage in tests
==============

Test suites such as ``qemucapabilitiestest`` or ``domaincapstest`` pick up the
test data automatically once the corresponding ``.xml`` or ``.replies`` file
is present in ``tests/qemucapabilitiesdata``.

Other test suites such as ``qemuxmlconftest`` provide macros which invoke test
cases using this data such as ``DO_TEST_CAPS_LATEST``.

Capturing QEMU capabilities
===========================

QEMU capabilities are captured by running the ``qemucapsprobe`` on the QEMU
binary on given architecture and then capturing the output. Since virtualization
acceleration is also probed it's required to run it on real hardware.

The capabilities dumps contain also host-specific information such as the exact
CPU definition of the machine where it was ran on, thus they can differ
significantly when run on other machines.

Probing QEMU
------------

Run the ``qemucapsprobe`` tool::

  $ LIBVIRT_BUILDDIR/tests/qemucapsprobe /path/to/qemu > output.replies

The tool spawns the qemu binary and performs probing as if libvirt would do that.
The QMP conversation between qemu and libvirt is dumped to stdout. User
running the probe must be able to access the virtualization accelerator (e.g.
have proper permissions on ``/dev/kvm``)

Generating the output files
---------------------------

Place the captured output ``.replies`` file into this directory and run::

  $ VIR_TEST_REGENERATE_OUTPUT=1 ninja test

This runs the test-suite instructing it to update and/or generate all new data
the test would normally expect.

Manual modifications the ``.replies`` file
==========================================

In certain cases it's impractical or impossible to re-generate the ``.replies``
file on a code change causing a change to the actual QMP query process.

In such case a careful manual modification of the ``.replies`` is tolerated.

To aid such modification the tool ``scripts/qemu-replies-tool.py`` can be
used.

The tool validates and updates the numbering of the entries in the QMP dump in
case something was modified.

The tool also allows programatic modification of the ``.replies`` file.

Fake test data dumps for certain architectures
==============================================

For some architectures it was impossible or impractical to fetch real capability
dumps. To ensure coverage of certain cases the dumps were collected from
corresponding binaries running on a different architecture.

Capabilities dumps for the following architectures are usually produced on real
hardware:

  - x86_64
  - aarch64
  - ppc64
  - s390x

In most other cases, x86_64 will be used as the host architecture. A fake caps
dump can be usually spotted by absence of KVM support.