At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the bootindex argument was already supported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the configfd argument was already supported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Added by commit fc66c1603c and not used since.
Also, the device was present in QEMU 1.5.0 so this capability
will not be needed if we ever decide to implement usb-net support.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We don't honour the QEMU default machine type anymore, always using the
libvirt chosen default instead. The QEMU argv parser, however, will need
to know the exacty QEMU default, so we must record that info.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The capability was usable since qemu 1.3 so we can remove all the
detection code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
For versions where we can probe that the arguments are optional we can
perform the probing by a schema query rather than sending a separate
command to do so.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Since we're not saving the platform-specific data into a cache, we're
not going to populate the structure, which in turn will cause a crash
upon calling virNodeGetSEVInfo because of a NULL pointer dereference.
Ultimately, we should start caching this data along with host-specific
capabilities like NUMA and SELinux stuff into a separate cache, but for
the time being, this is a semi-proper fix for a potential crash.
Backtrace (requires libvirtd restart to load qemu caps from cache):
#0 qemuGetSEVInfoToParams
#1 qemuNodeGetSEVInfo
#2 virNodeGetSEVInfo
#3 remoteDispatchNodeGetSevInfo
#4 remoteDispatchNodeGetSevInfoHelper
#5 virNetServerProgramDispatchCall
#6 virNetServerProgramDispatch
#7 virNetServerProcessMsg
#8 virNetServerHandleJob
#9 virThreadPoolWorker
#10 virThreadHelper
https: //bugzilla.redhat.com/show_bug.cgi?id=1612009
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
So the procedure to detect SEV support works like this:
1) we detect that sev-guest is among the QOM types and set the cap flag
2) we probe the monitor for SEV support
- this is tricky, because QEMU with compiled SEV support will always
report -object sev-guest and query-sev-capabilities command, that
however doesn't mean SEV is supported
3) depending on what the monitor returned, we either keep or clear the
capability flag for SEV
Commit a349c6c21c added an explicit check for "GenericError" in the
monitor reply to prevent libvirtd to spam logs about missing
'query-sev-capabilities' command. At the same time though, it returned
success in this case which means that we didn't clear the capability
flag afterwards and happily formatted SEV into qemuCaps. Therefore,
adjust all the relevant callers to handle -1 on errors, 0 on SEV being
unsupported and 1 on SEV being supported.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The field was added in qemu v0.13.0-rc0-731-g1ca4d09ae0 so all supported
qemu versions now use it.
There's a LOT of test fallout as we did not use capabilities close
enough to upstream for many of our tests.
Several tests had a 'bootindex' variant. Since they'd become redundant
they are also removed here.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU 2.12 introduced a new vfio-pci device option 'display=on/off/auto'.
This patch introduces the necessary capability.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since QEMU 2.10, it's possible to use a new type of display -
egl-headless which uses drm nodes to provide OpenGL support. This patch
adds a capability for that. However, since QEMU doesn't provide a QMP
command to probe it, we have to base the capability on specific QEMU
version.
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The original capabilities didn't include a patched kernel for spectre,
SPICE gl support and had xen support enabled which we already have
dropped.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Support for specifying it with the -device frontend was added recently.
Add a capability for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Based on qemu commit ab3257c281c1a1a91da1090ac9e38ddd8f860c63
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use qemuMonitorTestNewFromFileFull which allows to test commands used
along with providing replies. This has two advantages:
1) It's easier to see which command was used when looking at the files
2) We check that the used commands are actually in the correct order
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
QEMU version >= 2.12 provides support for launching an encrypted VMs on
AMD x86 platform using Secure Encrypted Virtualization (SEV) feature.
This patch adds support to query the SEV capability from the qemu.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
For getting the reply I queried the newest and oldest QEMU using
test/qemucapsprobe. From the differences I only extracted the reply to the new
QMP command and discarded the rest. For all the versions below the one which
added support for the new option I used the output from the oldest QEMU release
and for those that support it I used the output from the newest one.
In order to make doubly sure the reply is where it is supposed to be (the
replies files are very forgiving) I added the property to all the replies files,
reran the tests again and fixed the order in replies files so that all the
versions are reporting the new capability. Then removed that one property.
After that I used test/qemucapsfixreplies to fix the reply IDs.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extend the QEMU capabilities with tpm-emulator support.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU >= 2.12 will support passing of pre-opened file descriptors for
socket based character devices.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add the query of the device objects for the vmgenid device
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
The capability also represents that 'blockdev-add' is functional. It's
necessary to detect it via presence of 'blockdev-del' since blockdev-add
did not have the unsupported 'x-blockdev-add' version previously and
thus would be marked as present even if we could not use it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Commit 766d5c1b deprecated the capability, because we were assuming
it for every QEMU binary. At the time of the introduction, there
was no way to probe for this via QMP.
However since QEMU 1.5.0 (which is the earliest version we support)
we can rely on the query-command-line-options command to detect this
feature.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
As of v2.12.0-rc0~32^2 QEMU is capable specifying which display
device and head should the screendump be taken from. Track this
capability so that we can use it later in our virDomainScreenshot
API.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Let us update the existing xml and replies files for QEMU 2.12.0 on
s390x.
Used a z14 using a QEMU 2.12 GA build and the following sequence:
tests/qemucapsprobe /usr/bin/qemu-system-s390x > \
tests/qemucapabilitiesdata/caps_2.12.0.s390x.replies
VIR_TEST_REGENERATE_OUTPUT=1 tests/qemucapabilitiestest
VIR_TEST_REGENERATE_OUTPUT=1 tests/domaincapstest
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Support OpenGL acceleration capability when using SDL graphics.
Signed-off-by: Maciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Let us introduce the capability vfio-ccw for supporting the basic
channel I/O passthrough, which have been introduced in QEMU 2.10. The
current focus is to support dasd-eckd (cu_type/dev_type = 0x3990/0x3390)
as the target device.
Let us also introduce the capability QEMU_CAPS_CCW_CSSID_UNRESTRICTED
for virtual-css-bridge. This capability is based on the
cssid-unrestricted property which exists if QEMU no longer enforces
cssid restrictions based on ccw device types.
Vfio-ccw capability is dependent on the hidden virtual-css-bridge, so
that we are able to probe for the cssid-unrestriced property to make
sure the devices are visible to non-mcss-e enabled guests.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge
and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments
which identify support for ccw devices.
The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7.
The QEMU_CAPS_CCW capability is based on the existence of the QEMU type.
Let us also add the capability QEMU_CAPS_CCW to the tests which
require support for ccw devices.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability tracks if memory-backend-file has discard-data
attribute or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks if qemu has "qom-list-properties" monitor
command.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The -no-kvm-pit-reinjection option has been deprecated since
its introduction in QEMU 1.3. See commit <1569fa1>.
Drop the capability since all the QEMUs we support allow tuning
the kvm-pit properties via -global.
Also add the QEMU_CAPS_KVM_PIT_TICK_POLICY to the clock-catchup
tests, since expecting it to succeed with QEMU that does not
have kvm-pit makes no sense.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
QEMU on x86_64 (since v2.12) can support tpm-crb devices.
Introduce qemu capabilities for this device.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The NBD server in qemu supports TLS transport. Detect this capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU translates the cache mode of a disk internally into 3 flags.
'write-cache' is a flag of the frontend while others are flag of the
backing storage. Add capability which will allow expressing it via the
frontend attribute.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Detect whether QEMU supports the QMP query-cpus-fast API
and set QEMU_CAPS_QUERY_CPUS_FAST in this case.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
QEMU commit 1bd6152 changed the default behavior from whitelist
to blacklist and introduced a few sets of system calls.
Use the 'elevateprivileges' parameter of -sandbox as a witness
of this change.
https://bugzilla.redhat.com/show_bug.cgi?id=1492597
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Implied by QEMU >= 1.2.0.
Delete the negative test cases now that they always pass.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Implied by QEMU >= 1.2.0.
Also delete the now redundant disk-drive-copy-on-read test.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Last use was removed by commit 0586cf98 deprecating
QEMU_CAPS_DEVICE.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Implied by QEMU >= 1.2.0.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Fixed-up-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Implied by QEMU >= 1.2.0.
Delete this one first, because QEMU_CAPS_NODEFCONFIG is only used
when QEMU_CAPS_NO_USER_CONFIG is unsupported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We require QEMU >= 1.5.0, assume every QEMU supports it.
Sadly that does not let us trivially drop qemuMonitor's
priv->monJSON bool, because of qemuDomainQemuAttach.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This makes qemuDomainSupportsNetdev identical to
qemuDomainSupportsNicdev and leaves some code in
qemuDomainAttachNetDevice to be cleaned up later.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@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: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This capability will be set when the pcie-pci-bridge device
is available in the QEMU binary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@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: Andrea Bolognani <abologna@redhat.com>
QEMU on S390 (since v2.11) can support virtio input ccw devices.
Introduce qemu capabilities for these devices.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
QEMU on S390 (since v2.11) can support virtio-gpu-ccw device.
Let's introduce a new qemu capability for the device.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
The QEMU binary is compiled from the v2.12.0-rc0 tag.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Commit 4ae59411fa introduced the ability to make probing for
device properties conditional on a capability being set, but
didn't extend the use of this feature to existing devices.
This commit does the last bit of work, which results in a lot
of pointless QMP chatter no longer happening and our test suite
shrinking a fair bit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Let us introduce the xml and reply files for QEMU 2.11.0 on s390x.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.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: Jiri Denemark <jdenemar@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: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
All serial devices shoule have an associated capability.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All serial devices shoule have an associated capability.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel 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.
'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: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@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: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Andrea 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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@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=1308743
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John 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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John 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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
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: John Ferlan <jferlan@redhat.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: John Ferlan <jferlan@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The patch adds a capability for spapr-pci-host-bridge.numa_node.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This new capability can be used to detect whether a QEMU
binary supports the spapr-pci-host-bridge controller.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Every qemu version we support has QEMU_CAPS_CHARDEV, so stop
explicitly tracking it and blacklist it like we've done for many
other feature flags.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add new capability for the "-machine loadparm" QEMU option.
Add the capabilities replies/xml for s390x for QEMU 2.9.50.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Add kernel_irqchip=split/on to the QEMU command line
and a capability that looks for it in query-command-line-options
output. For the 'split' option, use a version check
since it cannot be reasonably probed.
https://bugzilla.redhat.com/show_bug.cgi?id=1427005
This patch maps /domain/cpu/cache element into -cpu parameters:
- <cache mode='passthrough'/> is translated to host-cache-info=on
- <cache level='3' mode='emulate'/> is transformed into l3-cache=on
- <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off
Any other <cache> element is forbidden.
The tricky part is detecting whether QEMU supports the CPU properties.
The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480,
earlier QEMU releases enabled host-cache-info by default and had no way
to disable it. If the property is present, it defaults to 'off' for any
QEMU until at least 2.9.0.
The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa.
Earlier versions worked as if l3-cache=off was passed. For any QEMU
until at least 2.9.0 l3-cache is 'off' by default.
QEMU 2.9.0 was the first release which supports probing both properties
by running device-list-properties with typename=host-x86_64-cpu. Older
QEMU releases did not support device-list-properties command for CPU
devices. Thus we can't really rely on probing them and we can just use
query-cpu-model-expansion QMP command as a witness.
Because the cache property probing is only reliable for QEMU >= 2.9.0
when both are already supported for quite a few releases, we let QEMU
report an error if a specific cache mode is explicitly requested. The
other mode (or both if a user requested CPU cache to be disabled) is
explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case
the QEMU defaults change. Any older QEMU already turns them off so not
doing so explicitly does not make any harm.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
CPU features which change their value from disabled to enabled between
two calls to query-cpu-model-expansion (the first with no extra
properties set and the second with 'migratable' property set to false)
can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo.
Since the code consuming qemuMonitorCPUModelInfo currently ignores the
migratable flag, this change is effectively changing the CPU model
advertised in domain capabilities to contain all features (even those
which block migration). And this matches what we do for QEMU older than
2.9.0, when we detect all CPUID bits ourselves without asking QEMU.
As a result of this change
<cpu mode='host-model'>
<feature name='invtsc' policy='require'/>
</cpu>
will work with all QEMU versions. Such CPU definition would be forbidden
with QEMU >= 2.9.0 without this patch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
If calling query-cpu-model-expansion on the 'host'/'max' CPU model with
'migratable' property set to false succeeds, we know QEMU is able to
tell us which features would disable migration. Thus we can mark all
enabled features as migratable.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
QEMU is able to tell us whether a CPU feature would block migration or
not. This patch adds support for storing such features in
qemuMonitorCPUModelInfo.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The event is fired when a given block backend node (identified by the
node name) experiences a write beyond the bound set via
block-set-write-threshold QMP command. This wires up the monitor code to
extract the data and allow us receiving the events and the capability.
QEMU 2.9 introduces the pcie-root-port device, which is
a generic version of the existing ioh3420 device.
Make the new device available to libvirt users.
The static CPU model expansion is designed to return only canonical
names of all CPU properties. To maintain backwards compatibility libvirt
is stuck with different spelling of some of the features, but we need to
use the full expansion to get the additional spellings. In addition to
returning all spelling variants for all properties the full expansion
will contain properties which are not guaranteed to be migration
compatible. Thus, we need to combine both expansions. First we need to
call the static expansion to limit the result to migratable properties.
Then we can use the result of the static expansion as an input to the
full expansion to get both canonical names and their aliases.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0
introduces a new "max" CPU model which can be used to ask QEMU what the
best CPU it can provide to a TCG domain is.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
While query-cpu-model-expansion returns only boolean features on s390,
but x86_64 reports some integer and string properties which we are
interested in.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Due to the extra architecture-specific logic, it's already
necessary for users to call virQEMUCapsHasPCIMultiBus(),
so the capability itself is just a pointless distraction.
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: Pavel Hrdina <phrdina@redhat.com>
When qmp query-cpu-model-expansion is available probe Qemu for its view of the
host model. In kvm environments this can provide a more complete view of the
host model because features supported by Qemu and Kvm can be considered.
Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
query-cpu-model-expansion is used to get a list of features for a given cpu
model name or to get the model and features of the host hardware/environment
as seen by Qemu/kvm.
Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Expected Qemu replies for versions 2.7 and 2.8 from the s390x
Qemu binary.
Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Qemu 2.8.0+ changes arguments structure for blockdev-add in the effort
to make it finally stable. Since libvirt recently added the detection of
gluster debug support relying on the old syntax we need to add the new
as well.
