Both are supported by qemu-2.11 and later, so we don't have to check for
them explicitly.
Note that QXL is supported only on x86_64, thus on other arches only the
capability for 'virtio-gpu' is removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that qemu fixed device unplug when JSON syntax is used with -device
we can re-enable the feature.
Since the old capability string representation is condemned by
suggesting filtering it as a workaround we must introduce a new string.
To achieve this the original capability position is renamed to
X_QEMU_CAPS_DEVICE_JSON_BROKEN_HOTPLUG and a new position with the
original name QEMU_CAPS_DEVICE_JSON is introduced to prevent us having
to change the rest of the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When -device is configured via JSON a bug [1] is triggered in qemu were
the DEVICE_DELETED event for the removal of the device frontend is no
longer delivered to libvirt. Without the DEVICE_DELETED event we don't
remove the corresponding entries in the VM XML.
Until qemu will be fixed we must stop using the JSON syntax for -device.
This patch removes the detection of the capability. The capability is
used only during startup of a fresh VM so we don't need to consider any
compaitibility steps for existing VMs.
For users who wish to use 'libvirt-7.9' and 'libvirt-7.10' with
'qemu-6.2' there are two possible workarounds:
- filter out the 'device.json' qemu capability '/etc/libvirt/qemu.conf':
capability_filters = [ "device.json" ]
- filter out the 'device.json' qemu capability via qemu namespace XML:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
[...]
<qemu:capabilities>
<qemu:del capability='device.json'/>
</qemu:capabilities>
</domain>
We must never again use the same capability name as we are now
instructing users to filter it as a workaround so once qemu is fixed
we'll need to pick a new capability value for it.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2036669
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2035237
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'sev-inject-launch-secret' qmp command is only available with
qemu >= 6.0.0. Introduce a capability for sev-inject-launch-secret.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This sev-guest object property indicates whether QEMU should
expose the kernel, ramdisk, cmdline hashes to the firmware
for measurement.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This reports what TPM features QEMU supports, provided that swtpm is
installed in the host.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It is now unused.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This reverts commit 58ba0f6a3d.
Conflict:
* src/qemu/qemu_capabilities.[ch]
Because other new cap flags had been added since the original
commit, reformatting was necessary to follow the "groups of
five" pattern.
* tests.qemucapabilitiesdata/caps_6.2.0.x86_64.xml
This file was added after the original commit that we
are reverting, so had to be manually edited to remove
the two capabilities.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
This reverts commit 618e8665db.
This is the first in a series of 10 commits that revert (in reverse
order) the changes to add the <acpi-hotplug-bridge state='on|off'/>
switch to libvirt domain XML, which unfortunately needs to be removed
due to QEMU developers discovering a flaw with the design of the QEMU
commandline switch used to implement the libvirt switch that will
likely result in a new and different method of selecting hotplug
modes. Because the libvirt switch has not been in any official
releases of libvirt, we are still able to remove it completely, rather
than deprecating it.
The original commits began with commit
58ba0f6a3d. The other original commit
IDs are documented in each revert commit.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
rbd encryption is new in qemu 6.1.0.
This commit adds capability probing for it.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
query-dirty-rate command is used for virsh domstats by default, but this
is available only on qemu >=5.2.0.
In this commit, add capability flag for query-dirty-rate first.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The capability reflects whether QEMU is capable of -device
virtio-*,ats=. Since the property was introduced in QEMU commit
v2.9.0-rc0~162^2~32 we can safely assume the property is always
present as the minimal version required is 2.11.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The capability reflects whether QEMU is capable of -device
virtio-*,iommu_platform=. Since the property was introduced in
QEMU commit v2.9.0-rc0~162^2~37 we can safely assume the property
is always present as the minimal version required is 2.11.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The flag will be used to switch use of JSON arguments for -device once
qemu will support it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The flag will be used to switch use of JSON arguments for -chardev once
qemu will support it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a capability that will be asserted once '-netdev' will accept
JSON. For now it will be dormant (only used by tests).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unify it with the upcoming capabilities for -netdev and -device.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 58ba0f6a3d added a capability which
is supported by all qemu versions we support. Remove it and the
associated dead code. Since the capability isn't present in any upstream
release we can delete it completely.
Specifically the commit itself states that it was introduced "around
(qemu) 2.1". The rest of the code handles properly that the feature is
used only on x86 with the i440fx machine so the capability is pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu added support for i440fx specific global boolean flag
PIIX4_PM.acpi-pci-hotplug-with-bridge-support
around version 2.1. This flag is enabled by default. When disabled, it
turns off acpi pci hotplug for cold plugged pci bridges in i440fx
machine types.
Very recently, in qemu version 6.1, the same global option was also
added for q35 machine types as well.
ICH9-LPC.acpi-pci-hotplug-with-bridge-support
This option turns on or off acpi based hotplug for cold plugged pcie
bridges like pcie root ports. This flag is also enabled by
default. Please refer to the following qemu changes:
c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug")
17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35")
This patch adds the corresponding qemu capabilities in libvirt. For
i440fx, the capability is detected as
QEMU_CAPS_PIIX_ACPI_HOTPLUG_BRIDGE. For q35, the capability is
detected as QEMU_CAPS_ICH9_ACPI_HOTPLUG_BRIDGE.
Please note that the test specific qemu capabilities .replies files
has already been updated as a part of regular refreshing them when a
new qemu version is released. Hence, no updates to those files are
required.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
The capability name piix4-acpi-root-hotplug-en is not conventional and
appreared to be confusing to some. "en" suffix is also incorrect as the
capability in qemu is used to both enable and disable hotplug on the pci root
bus on the i440fx. Hence, rename it to piix4.acpi-root-pci-hotplug so that it
is clearer, less confusing and more accurate.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
The following change in qemu added support for a global boolean flag specific
to i440fx machines that would turn off or on acpi based hotplug for pci root
bus:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The option is passed as "-global PIIX4_PM.acpi-root-pci-hotplug=on" etc in qemu
commandline. It is enabled by default. This patch adds the corresponding qemu
capabilities in libvirt as QEMU_CAPS_PIIX_ACPI_ROOT_PCI_HOTPLUG.
Please note that the test specific qemu capabilities .replies files has already
been updated as a part of regular refreshing them when a new qemu version is
released. Hence, no updates to those files are required.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
This capability tracks whether memory-backend-* supports .reserve
attribute which is going to be important for backends associated
with virtio-mem devices.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit introduces a new capability that reflects virtio-mem-pci
device support in QEMU:
QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI, /* -device virtio-mem-pci */
The virtio-mem-pci device was introduced in QEMU 5.1.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that it's no longer used, remove probing for it
and mark it as deprecated.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The code assumes that all supported qemu versions have this capability
so we can retire it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code assumes that the feature tracked by this capability always
exists.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code assumes that the feature tracked by this capability always
exists.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code assumes that the feature tracked by this capability always
exists.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To support virtio-blk queue-size option, this commit adds capability
detection to the option.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since we no longer use '-device sga' we can stop probing for this device
in our capabilities code.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 'set-action' QMP command allows modifying the behaviour when the
guest resets.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
They are no longer used as we now assume that all tuning caps are
present and in case some will be removed we'll need to use different
probing methods.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make it more obvious that we care about passing FDs on the commandline
before startup of qemu, which is used to avoid startup monitor polling.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
egl-headless graphics can be compiled out in qemu so we need to be able
to know whether the given qemu version support it.
Base the capability on the presence of the 'egl-headless' member in
'query-display-options' or imply it if 'query-display-options' is not
supported as we implied it before for all versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
SDL graphics can be compiled out in qemu so we need to be able to know
whether the given qemu version support it.
Base the capability on the presence of the 'sdl' member in
'query-display-options' or imply it if 'query-display-options' is not
supported as we implied it before for all versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
The command allows to query various display-related options. The absence
of the command will be used to imply certain video-related capabilities
before we would be able to detect them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
In libvirt we already use `query-command-line-options` QMP command but
that is useless as it doesn't provide correct data for `-machine`
option. So we need a new and better way to get that data.
We already use `qom-list-properties` to get options for specific machine
types so we can reuse it to get options for special `none` machine type
as a generic arch independent machine type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This flag will be used for the device virtio-gpu-gl-pci which is introduced
since QEMU 6.1.
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The feature is present in all supported qemu versions (>2.11) and there
isn't a reasonable way to detect it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is present in all supported qemu versions (>2.11) and there
isn't a reasonable way to detect it.
In addition the capability wasn't even used to gate any functionality
except for reporting the presence in the domain capabilities XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is present in all supported qemu versions (>2.11) and there
isn't a reasonable way to detect it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is present in all supported qemu versions (>2.11) and there
isn't a reasonable way to detect it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is present in all supported QEMU versions and there isn't a
more elegant way to detect it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All supported qemus have it, there isn't an elegant way to detect it and
it's unlikely to be ever removed on purpose.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The feature is no longer asserted. Remove the checks related to it and
make the code work properly with QEMU_CAPS_DEVICE_INTEL_IOMMU.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All supported qemu versions have 'query-qmp-schema' so we can remove the
check whether it exists and all logic conntected to it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All machine types which have PCI support multibus since qemu 2.0
according to the logic we had, thus we can remove all the machine type
and version checks which are now dead code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Historically, we declared pointer type to our types:
typedef struct _virXXX virXXX;
typedef virXXX *virXXXPtr;
But usefulness of such declaration is questionable, at best.
Unfortunately, we can't drop every such declaration - we have to
carry some over, because they are part of public API (e.g.
virDomainPtr). But for internal types - we can do drop them and
use what every other C project uses 'virXXX *'.
This change was generated by a very ugly shell script that
generated sed script which was then called over each file in the
repository. For the shell script refer to the cover letter:
https://listman.redhat.com/archives/libvir-list/2021-March/msg00537.html
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This property is exposed by QEMU on any PCI device, but we have to pick
some specific device(s) to probe it against. We expect that at least one
of the virtio devices will be present, so probe against them.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The capability is asserted if qemu supports the -compat
deprecated-input= and deprecated-output= settings to control what should
happen if deprecated fields are used in QMP.
This will be used for a developer/tester-oriented setting which will
aid us in catching use of deprecated settings sooner.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
This is available in QEMU with "ide-hd" and "scsi-hd" device
types. It was originally mistakenly added to the "scsi-block"
device type too, but later removed. This doesn't affect libvirt
since we restrict usage to device=disk.
When this property is not set then QEMU's default behaviour
is to not report any rotation rate information, which
causes most guest OS to assume rotational storage.
https://bugzilla.redhat.com/show_bug.cgi?id=1498955
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Starting from qemu-6.0 the parameters of -object/object-add are formally
described by the QAPI schema. Additionally this changes the nesting of
the properties as the 'props' nested object will be flattened to the
parent.
We'll need to detect whether qemu switched to this new approach to
generate the objects with proper nesting and also allow testing.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming commit will enable full backup support (incremental part
requires blockdev-reopen, which won't happen in qemu for at least
another release).
Add a capability that the 'blockdev-backup' job is supported by qemu
capped, but limited to when qemu supports QEMU_CAPS_BLOCKDEV.
We can also use it in the expression to enable
QEMU_CAPS_INCREMENTAL_BACKUP since it's a pre-requisite too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The -audiodev arg is a new way to configure audio devices in QEMU to
replace the QEMU_AUDIO_DRV env variable. This arg is not visible in
the "query-command-line-options" output since it is entirely QAPI
driven, not QemuOpts. It also isn't in "query-qmp-schema" though
since there's no QMP command that uses the Audiodev type yet.
So probe for the existance of this feature by looking for the
-vnc "audiodev" property. This won't let us determine which
precise audio backends QEMU has been built with, but for now
that's no worse than with env variables today.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The capability represents qemu's ability to setup mappings for migrating
block dirty bitmaps and is based on presence of the 'transform' property
of the 'block-bitmap-mapping' property of 'migrate-set-parameters' QMP
command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This was introduced in QEMU 2.2.0, and is visible by -vnc appearing in
the "query-command-line-options" data.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This capability tracks whether memory-backend-file has
"x-use-canonical-path-for-ramblock-id" attribute. Introduced into
QEMU by commit fa0cb34d2210cc749b9a70db99bb41c56ad20831. As of
QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9 the property
is considered stable by qemu despite the 'x-' prefix to preserve
compatibility with released qemu versions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This is a special CPU model similar to "-cpu host", so won't use our
normal CPU model detection logic.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@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>
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>
Similarly to previous commits, we can utilize domCaps to check if
graphics type is supported.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
In my recent commit of 5216304bfe I've moved RNG model check
from domain capabilities validator into qemu validator. During
that I had to basically duplicate RNG model to qemuCaps checks.
Problem with this approach is that after my commit qemu validator
and domCaps are disconnected and thus domCaps might report (in
general) different set of supported RNG models.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
In my recent commit of a33279daa8 I've moved video model check
from domain capabilities validator into qemu validator. During
that I had to basically duplicate video model to qemuCaps checks.
Problem with this approach is that after my commit qemu validator
and domCaps are disconnected and thus domCaps might report (in
general) different set of supported video models.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Now that the domCaps cache is history, this code is no longer
used and thus can be removed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.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>
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>
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>
We want to instantiate hostdevs via -blockdev too. Add a separate
capability for them for a clean transition. The new capability will be
enabled when QEMU_CAPS_BLOCKDEV is present once all code is prepared.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@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>
Previous commit removed the last usage of the function. Drop
virQEMUCapsCompareArch as well since virQEMUCapsCacheLookupByArch was
its only caller.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When listing CPU models, we need to filter the data based on sets
of permitted and forbidden CPU models.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.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>
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>
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>
Add io_uring value to capability replies.
The capability QEMU_CAPS_AIO_IO_URING will be used for io_uring aio mode,
introduced from QEMU 5.0, linux 5.1.
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This caps flag is set when the qemu binary supports the option
"hotplug" for pcie-root-port, ioh3420 (Intel pcie-root-port) and
xio3130-downstream (Intel pcie-downstream-port). If it's available,
it's possible to disable hotplugging/unplugging devices on a
particular port by adding ",hotplug=off" to the qemu device
commandline. This option first appears in qemu-5.0.0.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add the capability for QEMU's packed virtqueues for virtio that supposedly have
better cache utilization and performance compared to the default split queues.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The QEMU 9pfs 'multidevs' option exists since QEMU 4.2. Probe QEMU's
command line set though to check whether this option is really
available, and if yes enable this new QEMU_CAPS_FSDEV_MULTIDEVS
capability on libvirt side.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Detect the werror property on SCSI and virtio disks.
But clear it if the QEMU supports usb-storage device without it
also supporting this option for usb-storage.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This capability will be asserted once qemu stabilizes 'blockdev-reopen'.
For now we just add the capability so that we can introduce some code
that will use the reopening call. This will show our willingness to
adopt use of reopen and help qemu developers stabilize it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The capability is based on qemu's support of using blockdev-snapshot to
install backing chain also for images which are in use by a block-copy
job.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Detect the presence of the flag and make it available internally as
QEMU_CAPS_QMP_QUERY_NAMED_BLOCK_NODES_FLAT.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced by QEMU commit 98fc1ada4cf70af0f1df1a2d7183cf786fc7da05
virtio: add vhost-user-fs base device
Released in QEMU v4.2.0.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Andrea Bolognani <abologna@redhat.com>
We will use this capability to detect whether the QEMU binary
supports the kvm-no-adjvtime CPU feature.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The usability of a specific CPU mode may depend on machine type, let's
prepare for this by passing it to virQEMUCapsIsCPUModeSupported.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extend the QEMU capabilties with tpm-spapr support.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Presence of the virtio-net-pci option called "failover" indicates
support in a qemu binary of a simplistic bonding of a virtio-net
device with another PCI device. This feature allows migration of
guests that have a network device assigned to a guest with VFIO, by
creating a network bond device in the guest consisting of the
VFIO-assigned device and a virtio-net-pci device, then temporarily
(and automatically) unplugging the VFIO net device prior to migration
(and hotplugging an equivalent device on the migration
destination). (The feature is called "failover" because the bond
device uses the vfio-pci netdev for normal guest networking, but
"fails over" to the virtio-net-pci netdev once the vfio-pci device is
unplugged for migration.)
Full functioning of the feature also requires support in the
virtio-net driver in the guest OS (since that is where the bond device
resides), but if the "failover" commandline option is present for the
virtio-net-pci device in qemu, at least the qemu part of the feature
is available, and libvirt can add the proper options to both the
virtio-net-pci and vfio-pci device commandlines to indicate qemu
should attempt doing the failover during migration.
This patch just adds the qemu capabilities flag "virtio-net.failover".
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Every supported qemu is able to return the list of machine types it
supports so we can start validating it against that list. The advantage
is a better error message, and the change will also prevent having stale
test data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It is used to check if qemu is capable of rng-builtin object.
This object is added since qemu-4.2.0-rc0, commit 6c4e9d48.
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since v5.6.0-48-g270583ed98 we try to cache domain capabilities,
i.e. store filled virDomainCaps in a hash table in virQEMUCaps
for future use. However, there's a race condition in the way it's
implemented. We use virQEMUCapsGetDomainCapsCache() to obtain the
pointer to the hash table, then we search the hash table for
cached data and if none is found the domcaps is constructed and
put into the table. Problem is that this is all done without any
locking, so if there are two threads trying to do the same, one
will succeed and the other will fail inserting the data into the
table.
Also, the API looks a bit fishy - obtaining pointer to the hash
table is dangerous.
The solution is to use a mutex that guards the whole operation
with the hash table. Then, the API can be changes to return
virDomainCapsPtr directly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1791790
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The "ps2" bus is only available on certain machines like x86. On
machines like s390x, we should refuse to add a device to this bus
instead of silently ignoring it.
Looking at the QEMU sources, PS/2 is only available if the QEMU binary
has the "i8042" device, so let's check for that and only allow "ps2"
devices if this QEMU device is available, or if we're on x86 anyway
(so we don't have to fake the QEMU_CAPS_DEVICE_I8042 capability in
all the tests that use <input ... bus='ps2'/> in their xml data).
Reported-by: Sebastian Mitterle <smitterl@redhat.com>
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1763191
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
QEMU since 4.1.0 supports the "dies" parameter for -smp
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Simplify repeated code patterns by providing a new constructor taking
the QEMU binary name.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This capability tracks if qemu is capable of:
-drive file.driver=nvme
The feature was added in QEMU's commit of v2.12.0-rc0~104^2~2.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
The QEMU impl of the callback can directly use the QEMU capabilities
cache to resolve the emulator binary name, allowing virCapsPtr to be
dropped.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
To enable the virCapsPtr parameter to the post parse method to be
eliminated, the drivers must fetch the virCapsPtr from their own
driver via the opaque parameter, or use an alternative approach
to validate the parsed data.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
As part of a goal to eliminate the need to use virCapsPtr for anything
other than the virConnectGetCapabilies() API impl, cache the host arch
against the QEMU driver struct and use that field directly.
In the tests we move virArchFromHost() globally in testutils.c so that
every test runs with a fixed default architecture reported.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Blockdev is required to do incremental backups properly. Add a helper
function for locking out capabilities and export it to allow re-doing
the processing if a different code path modifies capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
The 'savevm' HMP command didn't work properly with blockdev as it tried
to do snapshot of everything including the protocol nodes accessing
files which are not snapshottable. Qemu fixed this bug so now we need to
detect it to allow enabling blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Initial implementation of 'auto-read-only' didn't reopen the backing
files when needed. For '-blockdev' to work we need to be able to tel
qemu to open a file read-only and change it during blockjobs as we label
backing chains with a sVirt label which does not allow writing. The
dynamic auto-read-only supports this as it reopens files when writing
is demanded.
Add a capability to detect that the posix file based backends support
the dynamic part.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The functions return virDomainCapsCPUModelsPtr and thus they should be
called *CPUModels for consistency. Functions called *CPUDefinitions will
work on qemuMonitorCPUDefsPtr.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function would return a valid virDomainCapsCPUModelsPtr with empty
CPU models list if query-cpu-definitions exists in QEMU, but returns
GenericError meaning it's not in fact implemented. This behaviour is a
bit strange especially after such virDomainCapsCPUModels structure is
stored in capabilities XML and parsed back, which will result in NULL
virDomainCapsCPUModelsPtr rather than a structure containing nothing.
Let's just keep virDomainCapsCPUModelsPtr NULL if the QMP command is not
implemented and change the return value to int so that callers can
easily check for failure or success.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some callers of virQEMUCapsGetCPUDefinitions will need to filter the
returned list of CPU models. Let's add the filtering parameters directly
to virQEMUCapsGetCPUDefinitions to avoid copying the CPU models list
twice.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Mirrors the existing QEMU_CAPS_X86_MAX_CPU.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Libvirt currently uses the VIR_AUTOUNREF macro for auto cleanup of
virObject instances. GLib approaches things differently with GObject,
reusing their g_autoptr() concept.
This introduces support for g_autoptr() with virObject, to facilitate
the conversion to GObject.
Only virObject classes which are currently used with VIR_AUTOREF are
updated. Any others should be converted to GObject before introducing
use of autocleanup.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@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>
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>
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>
This reverts commit 0cebb6422a.
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>
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>
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>
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>
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>
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>
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>
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>
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>
Support for kqemu was dropped in libvirt by commit 8e91a400c and even
back then we never set these capabilities when doing QMP probing.
Since no QEMU we aim to support has these, drop them completely.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Added in QEMU commit of v3.0.0-rc0~48^2~9 (then fixed by
v3.1.0-rc0~119^2~37) QEMU is replacing '-realtime mlock' with
'-overcommit mem-lock'. Add a capability to tell if we're dealing
new new enough qemu to use the replacement.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The '-realtime mlock' cmd line argument was introduced in QEMU
commit v1.5.0-rc0~190 which matches minimal QEMU version we
require. Therefore, the capability will always be present.
Apparently, nearly none of our xml2argv test cases had the
capability hence slightly bigger change under qemuxml2argvdata/.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If a management application wants to use firmware auto selection
feature it can't currently know if the libvirtd it's talking to
support is or not. Moreover, it doesn't know which values that
are accepted for the @firmware attribute of <os/> when parsing
will allow successful start of the domain later, i.e. if the mgmt
application wants to use 'bios' whether there exists a FW
descriptor in the system that describes bios.
This commit then adds 'firmware' enum to <os/> element in
<domainCapabilities/> XML like this:
<enum name='firmware'>
<value>bios</value>
<value>efi</value>
</enum>
We can see both 'bios' and 'efi' listed which means that there
are descriptors for both found in the system (matched with the
machine type and architecture reported in the domain capabilities
earlier and not shown here).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
virutil.(c|h) is a very gross collection of random code. Remove the enum
handlers from there so we can limit the scope where virtutil.h is used.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'blockdev-snapshot-sync' is present in QEMU since v0.14.0-rc0 and
'transaction' since v1.1.0 (52e7c241ac766406f05fa)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu added the 'drive-mirror' command in v1.3.0 (d9b902db3fb71fdc)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu added the 'block-commit' command in v1.3.0 (ed61fc10e8c8d2)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This was detected by the presence of 'block-stream' which is present in
qemu since v1.1 (db58f9c0605fa151b8c4)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There is one specific caller (testInfoSetArgs() in
qemuxml2argvtest.c) which expect the va_list argument to change
after returning from the virQEMUCapsSetVAList() function.
However, since we are passing plain va_list this is not
guaranteed. The man page of stdarg(3) says:
If ap is passed to a function that uses va_arg(ap,type), then
the value of ap is undefined after the return of that function.
(ap is a variable of type va_list)
I've seen this in action in fact: on i686 the qemuxml2argvtest
fails on the second test case because testInfoSetArgs() sees
ARG_QEMU_CAPS and calls virQEMUCapsSetVAList to process the
capabilities (in this case there's just one
QEMU_CAPS_SECCOMP_BLACKLIST). But since the changes are not
reflected in the caller, in the next iteration testInfoSetArgs()
sees the QEMU capability and not ARG_END.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
And adjust virQEMUCapsSetList to use it. It will also be used in future
patches.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
In some cases, the string representing architecture is different
in qemu and libvirt. That is the reason why we have
virQEMUCapsArchFromString() and virQEMUCapsArchToString(). So
far, we did not need them outside of qemu_capabilities code, but
this will change shortly. Expose them then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add a single QEMU_CAPS_VIRTIO_PCI_TRANSITIONAL that
will be set if any of the following qemu devices are found:
virtio-blk-pci-transitional
virtio-blk-pci-non-transitional
virtio-net-pci-transitional
virtio-net-pci-non-transitional
vhost-scsi-pci-transitional
vhost-scsi-pci-non-transitional
virtio-rng-pci-transitional
virtio-rng-pci-non-transitional
virtio-9p-pci-transitional
virtio-9p-pci-non-transitional
virtio-balloon-pci-transitional
virtio-balloon-pci-non-transitional
vhost-vsock-pci-transitional
vhost-vsock-pci-non-transitional
virtio-input-host-pci-transitional
virtio-input-host-pci-non-transitional
virtio-scsi-pci-transitional
virtio-scsi-pci-non-transitional
virtio-serial-pci-transitional
virtio-serial-pci-non-transitional
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The property allows to control the guest-visible content of the vendor
specific designator of the 'Device Identification' page of a SCSI
device's VPD (vital product data).
QEMU was leaking the id string of -drive as the value if the 'serial' of
the disk was not specified. Switching to -blockdev would impose an ABI
change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The split of ide-disk into the two separate devices was introduced by
qemu commit 1f56e32a7f4b3 released in qemu v0.15.
Note that when compared to the previous commit which made sure that no
disk related tests were touched, in this case it's not as careful.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The split of scsi-disk into the two separate devices was introduced by
qemu commit b443ae67 released in qemu v0.15.
All changes to test files are not really related to disk testing thanks
to previous refactors.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
This capability tracks if nvdimm has the unarmed attribute or not
for the nvdimm readonly xml attribute.
Signed-off-by: Luyao Zhong <luyao.zhong@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability tracks if memory-backend-file has the pmem
attribute or not.
Signed-off-by: Luyao Zhong <luyao.zhong@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability tracks if memory-backend-file has the align
attribute or not.
Signed-off-by: Luyao Zhong <luyao.zhong@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Require that all headers are guarded by a symbol named
LIBVIRT_$FILENAME
where $FILENAME is the uppercased filename, with all characters
outside a-z changed into '_'.
Note we do not use a leading __ because that is technically a
namespace reserved for the toolchain.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
