Since commit 44e7f029159ed701b4a1739ac711507ee53790ed
util: rewrite auto cleanup macros to use glib's equivalent
VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros
directly instead of our custom aliases.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Linux kernel 5.1 added a new PPC KVM capability named
KVM_PPC_CPU_CHAR_BCCTR_FLUSH_ASSIST, which is exposed to the QEMU guest
since QEMU commit 8ff43ee404d under a new sPAPR capability called
SPAPR_CAP_CCF_ASSIST. This cap indicates whether the processor supports
hardware acceleration for the count cache flush workaround, which
is a software workaround that flushes the count cache on context
switch. If the processor has this hardware acceleration, the software
flush can be shortened, resulting in performance gain.
This hardware acceleration is defaulted to 'off' in QEMU. The reason
is that earlier versions of the Power 9 processor didn't support
it (it is available on Power 9 DD2.3 and newer), and defaulting this
option to 'on' would break migration compatibility between the Power 9
processor class.
However, the user running a P9 DD2.3+ hypervisor might want to create
guests with ccf-assist=on, accepting the downside of only being able
to migrate them only between other P9 DD2.3+ hosts running upstream
kernel 5.1+, to get a performance boost.
This patch adds this new capability to Libvirt, with the name of
QEMU_CAPS_MACHINE_PSERIES_CAP_CCF_ASSIST.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Add a qemu capbility to see if the standalone ramfb device is available.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
QEMU 2.11 for ppc64 changed all CPU model names to lower case. Since
libvirt can't change the model names for compatibility reasons, we need
to translate the matching lower case models to the names known by
libvirt.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
086c19d69 added bochs-display capability but didn't fill in the info for
domain capabilities.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This capability enables comparison of CPU models via QMP.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Message-Id: <1568924706-2311-13-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This capability enables baselining of CPU models via QMP.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielh413@gmail.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Message-Id: <1568924706-2311-9-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Some older s390 CPU models (e.g. z900) will not report props as a
response from query-cpu-model-expansion. As such, we should make the
props field optional when parsing the return data from the QMP response.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-6-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When expanding a CPU model via query-cpu-model-expansion, any features
that were a part of the original model are discarded. For exmaple,
when expanding modelA with features f1, f2, a full expansion may reveal
feature f3, but the expanded model will not include f1 or f2.
Let's pass a virCPUDefPtr to the expansion function in preparation for
taking features into consideration.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Message-Id: <1568924706-2311-4-git-send-email-walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In the domain capabilities XML there are FW image paths printed.
There are two sources for the image paths (in order of
preference):
1) firmware descriptor files - as returned by
qemuFirmwareGetSupported()
2) a compile time list of FW:NRAM pairs which can be overridden
in qemu.conf
If either of those contains a duplicate FW image path (which is
a valid use case) it is printed twice in the capabilities XML.
While it's technically not a bug, it doesn't look good.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add a new all-covering capability which will be used to interlock
incremental backup support until all bits are ready.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Those new devices are available since QEMU 4.1.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The wrapper reports libvirt errors for the libxml2 function so that
the same does not have to be repeated over and over.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This reverts commit 0cebb6422a63f5a8289ae43a36f8f33eb9956a4c.
This capability is not used anywhere and also it is not contained
in any release so it's safe to just remove it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemu side is not merged in yet, so there is a chance that the
interface will change. Don't detect the capability just yet then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Now that we have qemuFirmwareGetSupported() so that it also
returns a list of FW image paths, we can use it to report them in
domain capabilities instead of the old time default list.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
The qemuFirmwareGetSupported() function is called from qemu
driver to generate domain capabilities XML based on FW descriptor
files. However, the function currently reports only some features
from domcapabilities XML and not actual FW image paths. The paths
reported in the domcapabilities XML are still from pre-FW
descriptor era and therefore the XML might be a bit confusing.
For instance, it may say that secure boot is supported but
secboot enabled FW is not in the listed FW image paths.
To resolve this problem, change qemuFirmwareGetSupported() so
that it also returns a list of FW images (we have the list
anyway). Luckily, we already have a structure to represent a FW
image - virFirmware.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
This object is being proposed to qemu upstream "Add dbus-vmstate
object". It handles data migration of external processes.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Datagram socket is available since qemu 4.0, commit
fdec16e3c2a614e2861f3086b05d444b5d8c3406 ("net/socket: learn to talk
with a unix dgram socket").
Required for slirp-helper communication.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
KVM style of PCI devices assignment was dropped in kernel in
favor of vfio pci (see kernel commit v4.12-rc1~68^2~65). Since
vfio is around for quite some time now and is far superior
discourage people in using KVM style.
Ideally, I'd make QEMU_CAPS_VFIO_PCI implicitly assumed but turns
out qemu-3.0.0 doesn't support vfio-pci device for RISC-V.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
QEMU 4.0.0 and newer automatically drops caches at the end of migration.
Let's check for this capability so that we can allow migration when disk
cache is turned on.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Acked-By: Peter Krempa <pkrempa@redhat.com>
qemuCaps is tied to a binary on disk. domCaps is tied to a combo
of binary+machine+arch+virttype values. For the qemu driver this almost
entirely translates to a permutation of qemuCaps though
Upcoming patches want to use the domCaps data store at XML validate
time, but we need to cache the data so we aren't repeatedly
regenerating it.
Add a domCapsCache hash table to qemuCaps. This ensures that the domCaps
cache is blown away whenever qemuCaps needs to be regenerated. Similarly
when qemuCaps is invalidated, the next call to virQEMUCapsCacheLookup
will unref qemuCaps and free our cache as well.
Adjust virQEMUDriverGetDomainCapabilities to search the cache and add
to it if we don't find a hit.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The model logic is taken from qemuDomainRNGDefValidate
Reviewed-by: Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Starting with QEMU 4.1 qemuMonitorCPUModelInfo structure in virQEMUCaps
stores only canonical feature names which may differ from the name used
by libvirt. We need translate these canonical names into libvirt names
for further consumption.
This fixes a bug in qemuConnectBaselineHypervisorCPU which would remove
all features for which libvirt's spelling differs from the QEMU's
preferred name. For example, the following result of
qemuConnectBaselineHypervisorCPU on my host with QEMU 4.1 is wrong:
<cpu mode='custom' match='exact'>
<model fallback='forbid'>Skylake-Client</model>
<vendor>Intel</vendor>
<feature policy='require' name='ss'/>
<feature policy='require' name='vmx'/>
<feature policy='require' name='hypervisor'/>
<feature policy='require' name='clflushopt'/>
<feature policy='require' name='umip'/>
<feature policy='require' name='arch-capabilities'/>
<feature policy='require' name='xsaves'/>
<feature policy='require' name='pdpe1gb'/>
<feature policy='require' name='invtsc'/>
<feature policy='disable' name='pclmuldq'/>
<feature policy='disable' name='lahf_lm'/>
</cpu>
The 'pclmuldq' and 'lahf_lm' should not be disabled in the baseline CPU
as they are supported by QEMU on this host.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Check whether qemu supports the bochs-display device and set a
capability. Update tests.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
With QEMU versions which lack "unavailable-features" we use CPUID based
detection of features which were enabled or disabled once QEMU starts.
Thus using MSR features with host-model would result in all of them
being marked as disabled in the active domain definition even though
QEMU did not actually disable them.
Let's make sure we add MSR features to host-model only when
"unavailable-features" property is supported by QEMU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is a generic replacement for the former virCPUx86DataAddFeature,
which worked on the generic virCPUDataPtr anyway.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
By default query-cpu-model-expansion only reports canonical names of all
CPU features. We do some magic and call the command twice to get all
possible spellings of the features, but being able to consume canonical
names will allow us to drop this magic.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When building QEMU command line, we should use the preferred spelling of
each CPU feature without relying on compatibility aliases (which may be
removed at some point).
The "unavailable-features" CPU property is used as a witness for the
correct names of the features in our translation table.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We will use it to check whether QEMU supports a specific CPU property.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far we always used libvirt's name of each CPU feature relying on
backward compatible aliases in QEMU. The new translation table can be
used whenever QEMU mandates or prefers canonical feature names.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We already have virQEMUCapsCPUFilterFeatures for filtering features
which QEMU does not know about. Let's move osxsave and ospke from
qemuFeatureNoEffect there.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add two capabilities for testing features required for the upcoming
virDomainBackupBegin: use block-dirty-bitmap-merge as the generic
witness of bitmap support needed for checkpoints (since all of the
bitmap management functionalities were finalized in the same qemu 4.0
release), and the bitmap parameter to nbd-server-add for pull-mode
backup support. Even though both capabilities are likely to be
present or absent together (that is, it is unlikely to encounter a
qemu that backports only one of the two), it still makes sense to keep
two capabilities as the two uses are orthogonal (full backups don't
require checkpoints, push mode backups don't require NBD bitmap
support, and checkpoints can be used for more than just incremental
backups).
Existing code is not affected by the new capabilities.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The function is renamed as virQEMUCapsProbeHostCPU and it does not get
the list of allowed CPU models from qemuCaps anymore. This is
responsibility is moved to the caller. The result is just a very thin
wrapper around virCPUGetHost mostly required mocking in tests.
The generic function is used in place of a direct call to virCPUGetHost
in virQEMUCapsInitHostCPUModel to make sure tests don't accidentally
probe host CPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
This capability can be used to figure out whether the
QEMU binary at hand supports the machine type property
we need in order to enable SMMUv3 IOMMU support.
Unfortunately we can't avoid probing the RISC-V binaries
along with the ARM ones, since both architectures have
their own 'virt' machine type.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Já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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel 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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The QOM type for machine types is the machine type name
followed by the -machine suffix. Since this is always the
case, we can make virQEMUCapsMachineProps more readable
and avoid repetition by not including the suffix there and
adding it automatically while processing the data; moreover,
when later on we will start figuring out which specific
versioned machine type to probe at runtime instead of doing
so statically, adding the suffix dynamically will become
necessary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel 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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Up until now we've probed machine type properties, along with
properties for other types, in virQEMUCapsProbeQMPDevices(), but
soon we're going to need some logic that is specific to machine
types and as such wouldn't quite fit into that function.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
QEMU commit 46ea94ca9cf ("qmp: query-current-machine with
wakeup-suspend-support") added a new QMP command called
'query-current-machine' that retrieves guest parameters that
can vary in the same machine model (e.g. ACPI support for x86 VMs
depends on the '--no-acpi' option). Currently, this API has a single
flag, 'wakeup-suspend-support', that indicates whether the guest has
the capability of waking up from suspended state.
Introduce a libvirt capability that reflects whether qemu has the
monitor command.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
My earlier commit be46f61326 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
be46f61326 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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
