This is the upstream part of a PCIe switch. It connects to a PCIe port
(but not PCI) on the upstream side, and can have up to 31
xio3130-downstream controllers (but no other types of devices)
connected to its downstream side.

This device will be used to implement the "pcie-switch-upstream-port"
model of pci controller.

This is a PCIE "root port". It connects only to a port of the
integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and
provides a single PCIe port that can have PCI or PCIe devices
hotplugged into it.

This device will be used to implement the "pcie-root-port" model of
pci controller.

Here we assume that if qemu supports generic PCI host controller,
it is a part of virt machine and can be used for adding PCI devices.

In qemu this is actually a PCIe bus, so we also declare multibus
capability so that 0'th bus is specified to qemu correctly as 'pcie.0'
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This capability specifies that qemu can implement generic PCI host
controller. It is often used for virtual environments, including ARM.
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>

PowerPC pseries based VMs do not support a floppy disk controller.
This prohibits libvirt from adding floppy disk for a PowerPC pseries VM.
Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com>

This reverts commit 7b401c3b.

Until libvirt is able to differentiate whether heads='1' is just a
leftover from previous libvirt or whether that's added by user on
purpose and also whether the domain was started with the support for
qxl's max_outputs, we cannot incorporate this patch into the tree
due to compatibility reasons.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Allows to specify maximum number of head to QXL driver.

Actually can be a compatiblity problem as heads in the XML configuration
was set by default to '1'.
Signed-off-by: NFrediano Ziglio <fziglio@redhat.com>

Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_CPU_PATH which is a
derivative of SYSFS_SYSTEM_PATH

Use cpupath for nodeCapsInitNUMAFake and remove SYSFS_CPU_PATH

Add the sysfs_prefix argument to the call to allow for setting the
path for tests to something other than SYSFS_SYSTEM_PATH.

Thanks to Juan's work QEMU finally emits an event whenever migration
state changes.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The capability was not used up to the feature freeze.

This reverts commit 7f3515b4.

There's a small formatting problem in the function. One line is
not correctly indented. Fix this.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

A single-line 'if' body should not be encased in curly braces. Our
syntax-check enforces it. Introduced in 7f3515b4

This capability specifies that "virt" machine on ARM has PCI controller. Enabled when version is at least 2.3.0.
Signed-off-by: NPavel Fedin <p.fedin@samsung.com>

Some machine types are only reported as canonical names for other
machine types, which make it a bit harder to find what machine types are
supported by a specific QEMU binary. Ideally, one would just use
/capabilities/guest/arch[@name='...']/machine/text() XPath to get a list
of all supported machine types, but it doesn't work right now.

For example, we report

    <machine canonical='pc-i440fx-2.3' maxCpus='255'>pc</machine>

in guest capabilities, but the corresponding

    <machine maxCpus='255'>pc-i440fx-2.3</machine>

is missing.

This is a result of QMP probing. With "-machine ?" parsing QEMU sends
us two lines:

pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.3)
pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996) (default)

while query-machines QMP command reports both in the same entry:

{"name": "pc-i440fx-2.3", "is-default": true, "cpu-max": 255, "alias": "pc"}

Let's make sure we always report separate <machine/> for both the
canonical name and its alias and using the canonical name as the default
machine type (i.e., inserting it before its alias) in case is-default is
true.

https://bugzilla.redhat.com/show_bug.cgi?id=1229666Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

With a few exceptions, we assume that qemu binary for given
architecture has form of qemu-system-$arch. Well, openrisc is yet
another exception. It's binary is called qemu-system-or32.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The support for this was added in QEMU with commit
830d70db692e374b55555f4407f96a1ceefdcc97.  Unfortunately we have to do
another ugly version-based capability check.  The other option would be
not to check for the capability at all and leave that to qemu as it's
done with multiqueue tap devices.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We need to use qemu-system-aarch64 to run armv7l KVM VMs on an aarch64
host.

And it always has, so advertise it similarly to i686

qemu 2.3.0 added the -cpu host,aarch64=off option, which allows using
qemu-system-aarch64 KVM to run armv7l VMs.

Add a capabilities check for it, wire it up in qemu_command, and test
the command line generation.

Rather than an algorithm based solely on libvirtd ctime to refresh the
capabilities add the element of the libvirt build version into the equation.
Since that version wouldn't be there prior to this code being run - don't
fail on reading the capabilities if not found. In this case, the cache
will always be rebuilt when a new libvirt version is installed.

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

Original commit id 'cbde3589' indicates that the cache file would be
discarded if either the QEMU binary or libvirtd 'ctime' changes; however,
the code only discarded if the QEMU binary time didn't match or if the
new libvirtd ctime was later than what created the cache file.

Since many factors come into play with 'ctime' adjustments (including
perhaps turning back the hands of time), change the logic to also force
a refresh if the ctime of libvirt is different than what's in the cache.

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

Implementation is pretty straight-forward. Of course, not all qemus
out there supports the device, so new capability is introduced and
checked prior each use of the device.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Introduces two new -machine option parameters to the QEMU command to
enable/disable the CPACF protected key management operations for a guest:

    aes-key-wrap='on|off'
    dea-key-wrap='on|off'

The QEMU code maps the corresponding domain configuration elements to the
QEMU -machine option parameters to create the QEMU command:

    <cipher name='aes' state='on'>   --> aes-key-wrap=on
    <cipher name='aes' state='off'>  --> aes-key-wrap=off
    <cipher name='dea' state='on'>   --> dea-key-wrap=on
    <cipher name='dea' state='off'>  --> dea-key-wrap=off
Signed-off-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>
Signed-off-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Coverity complains over the [n]values pairing in virQEMUCapsFreeStringList
and rather than make a bunch if "if values" checks prior to calling, by
just adding the values check inside the free function we avoid the chance
that somehow nvalues is > 0, while values == NULL

The vmport machine argument works with pc machine kind, not with xen for
example.

Set the capability based on qmp query, or qemu version.  The qmp query
includes vmport with 2.2, but no longer with 2.3. It lists only
non-machine specific capabilities, so check the qemu version too until a
machine-specific query is supported.

This is basically turning qemuDomObjEndAPI into a more general
function. Other drivers which gets a reference to domain objects may
benefit from this function too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This revealed that GuestDefaultEmulator was a bit buggy, capable
of returning an emulator that didn't match the passed domain type. Fix
up the test suite input to continue to pass.

Rather than an opencoded string. This should be a no-op

On arm, we probe for virtio-*-pci devices, but use their
virtio-*-device variants.

Set the capabilities based on the -device variants as well,
to make them work with qemus with the PCI devices compiled out.

Wikipedia's list of common misspellings [1] has a machine-readable
version.  This patch fixes those misspellings mentioned in the list
which don't have multiple right variants (as e.g. "accension", which can
be both "accession" and "ascension"), such misspellings are left
untouched.  The list of changes was manually re-checked for false
positives.

[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machinesSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

A helper that never returns an error and treats bits out of bitmap range
as false.

Use it everywhere we use ignore_value on virBitmapGetBit, or loop over
the bitmap size.

When creating qemu capabilities, a dummy virDomainObj is created just
because our monitor code expects that. However, the object is created
locked already. Then, under cleanup label, we simply unref the object
which results in whole domain object to be disposed. The object lock
is destroyed subsequently, but hey - it's still locked:

==24845== Thread #14's call to pthread_mutex_destroy failed
==24845==    with error code 16 (EBUSY: Device or resource busy)
==24845==    at 0x4C3024E: pthread_mutex_destroy (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==24845==    by 0x531F72E: virMutexDestroy (virthread.c:83)
==24845==    by 0x5302977: virObjectLockableDispose (virobject.c:237)
==24845==    by 0x5302A89: virObjectUnref (virobject.c:265)
==24845==    by 0x1DD37866: virQEMUCapsInitQMP (qemu_capabilities.c:3397)
==24845==    by 0x1DD37CC6: virQEMUCapsNewForBinary (qemu_capabilities.c:3481)
==24845==    by 0x1DD381E2: virQEMUCapsCacheLookup (qemu_capabilities.c:3609)
==24845==    by 0x1DD30F8A: virQEMUCapsInitGuest (qemu_capabilities.c:744)
==24845==    by 0x1DD31889: virQEMUCapsInit (qemu_capabilities.c:1020)
==24845==    by 0x1DD7DD36: virQEMUDriverCreateCapabilities (qemu_conf.c:888)
==24845==    by 0x1DDC57C0: qemuStateInitialize (qemu_driver.c:803)
==24845==    by 0x53DC743: virStateInitialize (libvirt.c:777)
==24845==
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The pc-dimm device represents a RAM memory module.

Not all machine types support all devices, device properties, backends,
etc. So until we create a matrix of [machineType, qemuCaps], lets just
filter out some capabilities before we return them to the consumer
(which is going to make decisions based on them straight away).
Currently, as qemu is unable to tell which capabilities are (not)
enabled for given machine types, it's us who has to hardcode the matrix.
One day maybe the hardcoding will go away and we can create the matrix
dynamically on the fly based on a few monitor calls.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It will come handy in the near future when we will filter some
capabilities based on it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>