My earlier commit be46f613 was incomplete. It removed caching of
microcode version in the CPU driver, which means the capabilities XML
will see the correct microcode version. But it is also cached in the
QEMU capabilities cache where it is used to detect whether we need to
reprobe QEMU. By missing the second place, the original commit
be46f613 made the situation even worse since libvirt would report
correct microcode version while still using the old host CPU model
(visible in domain capabilities XML).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
(cherry picked from commit 673c62a3)

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130

Conflicts:
	src/qemu/qemu_capabilities.c
            - virQEMUCapsCacheLookupByArch refactoring (commits
              7948ad41 and 1a3de670) are missing
            - commit a7424faf "Force QMP capability probing" is
              missing downstream
Signed-off-by: NDaniel P. Berrangé <berrange@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>

It breaks the build and it is not really useful for anything.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Whenever a different kernel is booted, some capabilities related to KVM
(such as CPUID bits) may change. We need to refresh the cache to see the
changes.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@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>

ncpus would be -1 on error and the cleanup for loop would not be skipped
in this case.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in
qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In status XML, we do not store the QEMU version information, we only
format all the capabilities. We dropped QEMU_CAPS_PCI_MULTIBUS
in commit 5b783379 which was released in libvirt 3.2.0.

Therefore the only way of telling if the already running domain
at the time of daemon restart has been started with a QEMU that does
use 'pci.0' or not on PPC is to look at the pci-root controller's
alias. This is not an option if the domain has a user-specified alias
for the pci-root.

Instead of reintroducing the capability, assume 'pci.0' when we have
no version information. That way the only left broken use case would
be the combination of user aliases and very old QEMU.

Partially reverts commit 3a37af1e.

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

We do not fill out qemuCaps->arch when parsing status XML.

Use def->os.arch like we do for PPC.

This fixes hotplug after daemon restart for domains that use
a user alias for the implicit pci-root on x86.

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

Adjust function descriptions of virQEMUCapsInitCPUModelS390 and
virQEMUCapsInitCPUModel to the changes introduced with
commitID 74fc32a9.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.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>

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.

Libvirt prints an error on startup when it is missing host cpu model
information for any queried qemu binary. On s390 we only have host cpu model
information for kvm enabled qemu instances. So when virt type is not kvm, this
is actually not an error on s390.

This patch adds virt type as a parameter to virQEMUCapsInitCPUModelS390, and a
new return code 2 for virQEMUCapsInitCPUModel and virQEMUCapsInitCPUModelS390.
If the virt type is not kvm then we skip printing the scary error message
and return 2 because this case is actually expected behavior. The new return
code is meant to differentiate between the failure case and the case where we
simply expect the cpu model information to be unattainable.
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

'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>

This function only queries domain @def. It doesn't change it.
Therefore it should take const pointer.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a separate capability for the sclplmconsole device, and check it
specifically instead of using QEMU_CAPS_DEVICE_SCLPCONSOLE for that too.
Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Give a better name to the capability for the sclpconsole device.
Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Up until now we assumed the spapr-vty device would always be
present, which is not very nice. Check for its availability before
using it instead.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Starting from qemu 2.11, the `-device vmcoreinfo` will create a fw_cfg
entry for a guest to store dump details, necessary to process kernel
dump with KASLR enabled and providing additional kernel details.

In essence, it is similar to -fw_cfg name=etc/vmcoreinfo,file=X but in
this case it is not backed by a file, but collected by QEMU itself.

Since the device is a singleton and shouldn't use additional hardware
resources, it is presented as a <feature> element in the libvirt
domain XML.

The device is arm/x86 only for now (targets that support fw_cfg+dma).

Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1395248Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

Truncate the output so that it is only as big as is needed to fit all
the bits, not all the units from the map.  This will be needed in the
future in order to properly format bitmaps for kernel's sysfs files.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This follows the virBitmapToData() function and, similarly to
virBitmapNewData(), we'll be able to have virBitmapNewString() later
on without name confusion.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Most of the time it's okay to leave this up to negotiation between
the guest and the host, but in some situations it can be useful to
manually decide the behavior, especially to enforce its availability.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1308743Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Don't leak @blockNodes in the loop.

==226576== 7,120 bytes in 60 blocks are definitely lost in loss record 122 of 125
==226576==    at 0x4835214: calloc (vg_replace_malloc.c:711)
==226576==    by 0x4950D7B: virAllocN (viralloc.c:191)
==226576==    by 0x49EB5BB: virXPathNodeSet (virxml.c:676)
==226576==    by 0x104DB67: virQEMUCapsLoadCPUModels (qemu_capabilities.c:3738)
==226576==    by 0x105510D: virQEMUCapsLoadCache (qemu_capabilities.c:3929)
==226576==    by 0x104459F: qemuTestParseCapabilities (testutilsqemu.c:498)
==226576==    by 0x1040DC9: testQemuCapsCopy (qemucapabilitiestest.c:105)
==226576==    by 0x1041F07: virTestRun (testutils.c:180)
==226576==    by 0x1040B45: mymain (qemucapabilitiestest.c:181)
==226576==    by 0x104320F: virTestMain (testutils.c:1119)
==226576==    by 0x1041149: main (qemucapabilitiestest.c:193)
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Even though only family and model are used for matching CPUID data with
CPU models from cpu_map.xml, stepping is used by x86DataFilterTSX which
is supposed to disable TSX on CPU models with broken TSX support. Thus
we need to start parsing stepping from QEMU to make sure we don't
disable TSX on CPUs which provide working TSX implementation. See the
following patch for a real world example of such CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Gather query-cpu-definitions results and use them for testing CPU model
usability blockers in CPUID to virCPUDef translation.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The "preferred" parameter is not used by any caller of cpuDecode
anymore. It's only used internally in cpu_x86 to implement cpuBaseline.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

All APIs which expect a list of CPU models supported by hypervisors were
switched from char **models and int models to just accept a pointer to
virDomainCapsCPUModels object stored in domain capabilities. This avoids
the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated
list of model names and also allows the various cpu driver APIs to
access additional details (such as its usability) about each CPU model.
Signed-off-by: NJiri Denemark <jdenemar@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: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When a hypervisor marks a CPU model as unusable on the current host, it
may also give us a list of features which prevent the model from being
usable. Storing this list in virDomainCapsCPUModel will help the CPU
driver with creating a host-model CPU configuration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

Some distros (see diff) chose to backport QMP support rather than rebase
to newer version of qemu. As a hack they added the string 'libvirt' to
the qemu -help output. Remove this as downstream-only hacks should be
carried by downstream and not litter upstream.

This effectively reverts commit ff88cd59

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>

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

The filter only needs to know the CPU architecture. Passing
virQEMUCapsPtr as opaque is a bit overkill.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Interestingly, none of the qemus we have caps for supported it ...
Reviewed-by: NEric Blake <eblake@redhat.com>