QEMU has the ability to mark machine types as deprecated. This should be
exposed to management applications in the capabilities.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU has the ability to mark CPUs as deprecated. This should be exposed
to management applications in the domain capabilities.
This attribute is only set when the model is actually deprecated.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add the capabilities test data for the next qemu development cycle so
that we stay up to date.
Based on v5.2.0-1374-g9cd69f1a27
Notable changes detected by libvirt are the new machine types and
'intel-pt-lip', 'avx512-fp16', 'kvm-msi-ext-dest-id' cpu features
reported by qemu.
Other qemu changes not detected by libvirt include removal of the
'change' command, addition of 'sev-inject-launch-secret', 'yank',
'query-yank' commands and other device properties.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit introduces a new capability that reflects virtio-pmem-pci
device support in qemu:
QEMU_CAPS_DEVICE_VIRTIO_PMEM_PCI, /* -device virtio-pmem-pci */
The virtio-pmem-pci device was introduced in QEMU 4.1.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Let us introduce the xml and reply files for QEMU 5.2.0 on s390x.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
qemu-5.2 is out! Let's update the capabilities for the final version.
Note that the 'enable-fips' feature vanishing in this update is expected
as the removal was tied to a version check (see commit 7b1ed1cd73 ).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Probing for the NCR53C90 controller is a little unusual. The
qom-list-types QMP command returns a list of all types known to
the QEMU binary. It does not distinguish devices which are user
creatable from those which are built-in.
Any QEMU target that supports PCI will have the DC390 / AM53C974
devices because they are PCI based. Due to code dependencies
in QEMU though, existence of these two devices will also pull in
the NCR53C90 device (called just 'esp' in QEMU). The NCR53C90 is
not user-creatable and can only be used when built-in to the
machine type.
This is only the case on sparc machines, and certain mips64 and
m68k machines. IOW, we don't rely on qom-list-types as a guide
for existence of NCR53C90, as it shouldn't really exist in most
QEMU binaries.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The QEMU 9pfs 'fmode' and 'dmode' options have existed since QEMU 2.10.
Probe QEMU's command line set to check whether these options are
available, and if yes, enable this new QEMU_CAPS_FSDEV_CREATEMODE
capability on libvirt side.
Signed-off-by: Brian Turek <brian.turek@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Now that qemu stabilized it's interface and we've switched to the new
design we can re-enable use of 'block-export-add'
This reverts commit b87cfc957f
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
qemu decided to modify the arguments of 'block-export-add' to include an
array of bitmaps rather than a single bitmap.
Since we've added the code prior to qemu setting the interface in stone
and thus it will be changed incompatibly and we already have tests for
the new interface we need to update the code and qemu capabilities data
at the same time.
Use a array of bitmaps as the 'bitmaps' argument instead of 'bitmap' and
bump qemu capabilities for the upcoming 5.2.0 release to
v5.1.0-2827-g2c6605389c
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
We use the capability to switch to using 'block-export-add' in the
upcoming qemu release instead of the at the same time deprecated
'nbd-server-add'.
Unfortunately qemu wants to change the interface of 'block-export-add'
before the release. Since we've tried to stay up to date and added the
code before it was written in stone, we need to disable the use of the
new interface for the upcoming libvirt release so that we don't have a
version of libvirt which would not work with the upcoming qemu version.
Remove the detection of 'block-export-add' until we are more sure how
the qemu interface will look.
This patch partially reverts commit adb9f7123a
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Use of the -enable-fips option is being deprecated in QEMU >= 5.2.0. If
FIPS compliance is required, QEMU must be built with libcrypt which will
unconditionally enforce it.
Thus there is no need for libvirt to pass -enable-fips to modern QEMU.
Unfortunately there was never any way to probe for -enable-fips in the
first instance, it was enabled by libvirt based on version number
originally, and then later unconditionally enabled when libvirt dropped
support for older QEMU. Similarly we now use a version number check to
decide when to stop passing -enable-fips.
Note that the qemu-5.2 capabilities are currently from the pre-release
version and will be updated once qemu-5.2 is released.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Recent versions of qemu added the -netdev vhost-vdpa device. This
capability allows libvirt to know whether this is supported.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The 'block-export-add' QMP command is a replacement for 'nbd-server-add'
and will allow greater flexibility. Add a capability so that we can
switch to it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update to commit v5.1.0-2207-g96292515c0
Recent changes include deprecation of 'nbd-server-add' and addition of
'block-export-add'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch will introduce the free-page-reporting feature capabilities
that are in qemu 5.1
Signed-off-by: Nico Pache <npache@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The machine structure has another (optional) attribute:
default-ram-id, which specifies the alias of the default RAM
object. While the alias is private, it can never change in order
to not break migration. QEMU uses the alias when allocating
regular, not NUMA memory. In order to switch to new command line
and maintain migration, save this ID.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This capability tracks whether "usb-host" device has "hostdevice"
attribute. This attribute allows us to specify full path to the
USB device ("/dev/bus/usb/$bus/$dev") but more importantly, since
QEMU uses qemu_open() for this attribute it allows us to pass
pre-opened FD and have QEMU not bother with opening the file at
all.
The attribute was added in v5.1.0-rc0~71^2~1 QEMU commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Mid-cycle caps resync. Notable change is that virtio-blk enables
multiqueue by default and the addition of
'calc-dirty-rate'/'query-dirty-rate' QMP commands.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The machine types for this cycle were already added and qemu also added
a property for the machine type object called "default-ram-id".
Also "block-bitmap-mapping" is supported as a migration parameter.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu-v5.1.0 is released now. There weren't any noticable changes since
our last update to 'rc2'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Note that 'numa-mem-supported' turned off for certain machine types
which in turn forced us to generate a newer command line in certain
tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This capability tracks whether QEMU is capable of defining HMAT
ACPI table for the guest.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Expose the TPM Proxy support for PPC64 guests by creating a new
cap called QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY.
This device is part of the machinery the guest need to orchestrate
with the PPC64 Ultravisor the transition to the Secure VM (SVM)
mode. Inside QEMU, this device will be used with the H_TPM_COMM
hypercall to connect with the TPM Resource Manager, enabling
the guest to open and close TPM sessions with the host TPM.
Tested-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Format the address width attribute. Depending on the version of
QEMU it is named 'aw-bits' or 'x-aw-bits'.
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These parameters were originally set via dedicated commands which are
now deprecated. We want to use migrate-set-parameters instead if
possible.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This capability tracks whether QEMU supports -fw_cfg command line
option, more specifically whether it allows specifying filename.
There are some releases of QEMU which support -fw_cfg but not
filename. If this is ever a problem we can refine the capability
later on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU added the machine types for the 5.1 release so let's update them.
Other notable changes are 'cpu-throttle-tailslow' migration property,
'zlib' compression for qcow2 images and absrtact socket support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There is 'numa-mem-supported' machine attribute which specifies
whether '-numa mem=' is supported. Store it in our capabilities
as it will be used in later commits when building the command
line.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability flags support for `-device pvscsi`, which provides the
VMware paravirtual SCSI controller.
Signed-off-by: Chris Jester-Young <cky@cky.nz>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Historically the 'scsi' passthrough feature of virtio-blk-pci
was enabled by default. Libvirt was disabling it due to security
implications outlined in libvirt commit v0.9.9-4-g177db08775 if it was
not explicitly requested. In qemu commit v2.4.0-1566-ged65fd1a27 the
default value was changed to disabled in preparation for virtio-1.
Starting from QEMU-5.0 the 'scsi' property was also deprecated. There
replacement for the functionality is to use 'virtio-scsi' for the
purpose. This isn't a direct replacement though.
Add capability named QEMU_CAPS_VIRTIO_BLK_SCSI_DEFAULT_DISABLED which
allows us to stop formatting the 'scsi=' property if it's disabled by
default and not requested so that we don't use deprecated features.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The churn in the output files is caused primarily by the fact that
blockdev support has been introduced.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The churn in the output files is caused primarily by the fact that
replies were generated on a POWER9 machine, which is good because
we didn't have coverage of that before.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Start the new capability file for the new development cycle of QEMU.
Note that compared to previous version this was generated on an AMD cpu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since QEMU 2.10 it is possible to disable TCG when building
QEMU. Introduce a capability that reflects this.
Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
IBS (Indirect Branch Speculation) is the last capability added
in QEMU 2.12 related to Spectre mitigation for Power. It was
added in commit 4be8d4e7d935.
This patch introduces it as QEMU_CAPS_MACHINE_PSERIES_CAP_IBS.
Like CFPC and SBBC, users might want to tune in IBS based on
their HW and guest OS requirements, and it's better to do it
so in a proper Libvirt feature than to put QEMU arguments
in the middle of the domain XML.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
SBBC (Speculation Barrier Bounds Checking) is another capability
related to Spectre mitigation efforts in Power processors. It
was implemented in QEMU 2.12 by commit 09114fd81799.
This patch introduces it as QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC to
be implemented in the next patch. Like the case with the now
implemented CFPC, exposing this feature in the XML allows for
a cleaner way for users to tune the SBBC accordingly, given
that not all hypervisor and guest setups supports this
Spectre mitigation.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
CFPC (Cache Flush on Privilege Change) is one of the capabilities
added to QEMU to mitigate Spectre vulnerabilities in Power chips.
It was implemented in QEMU 2.12 by commit 6898aed77f46.
This capability is still used today due to differences in how
the host setup (hardware and firmware/kernel) can handle this
mitigation. Its default value also varies with the pseries machine
version of the time. There's also certain OSes, like AIX, that
might not support the default value of the pseries machine the
guest uses.
Exposing this in the Libvirt XML as a feature will allow users to tune
CFPC values in a cleaner way, instead of hacking parameters in
<qemu:commandline> elements.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
