Commit 21373feb added support for primary virtio-vga device but it was
checking for virtio-gpu. Let's check for existence of virtio-vga if we
want to use it.
Virtio video device is currently represented by three different models
*virtio-gpu-device*, *virtio-gpu-pci* and *virtio-vga*. The first two
models are tied together and if virtio video devices is compiled in they
both exist. However, the *virtio-vga* model doesn't have to exist on
some architectures even if the first two models exist. So we cannot
group all three together.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We generally uses QEMU_CAPS_DEVICE_$NAME to probe for existence of some
device and QEMU_CAPS_$NAME_$PROP to probe for existence of some property
of that device.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If QEMU in question supports QMP, this capability is set if
QEMU_CAPS_DEVICE_QXL was set based on existence of "-device qxl". If
libvirt needs to parse *help*, because there is no QMP support, it
checks for existence of "-vga qxl", but it also parses output of
"-device ?" and sets QEMU_CAPS_DEVICE_QXL too.
Now that libvirt supports only QEMU that has "-device" implemented it's
safe to drop this capability and stop using it.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This patch simplifies QEMU capabilities for QXL video device. QEMU
exposes this device as *qxl-vga* and *qxl* and they are both the same
device with the same set of parameters, the only difference is that
*qxl-vga* includes VGA compatibility.
Based on QEMU code they are tied together so it's safe to check only for
presence of only one of them.
This patch also removes an invalid test case "video-qxl-sec-nodevice"
where there is only *qxl-vga* device and *qxl* device is not present.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The intel-iommu device has existed since QEMU 2.2.0, but
it was only possible to create it with -device since
QEMU 2.7.0, thanks to:
commit 621d983a1f9051f4cfc3f402569b46b77d8449fc
Author: Marcel Apfelbaum <marcel@redhat.com>
Date: Mon Jun 27 18:38:34 2016 +0300
hw/iommu: enable iommu with -device
Use the standard '-device intel-iommu' to create the IOMMU device.
The legacy '-machine,iommu=on' can still be used.
The libvirt capability check & command line formatting code
is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive.
This fixes it to use iommu=on instead.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The list of supported CPU models in domain capabilities is stored in
virDomainCapsCPUModels. Let's use the same object for storing CPU models
in QEMU capabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Just like in the previous commit, teach qemu driver to detect
whether qemu supports this configuration knob or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
QEMU reports whether 'query-hotpluggable-cpus' is supported for a given
machine type. Extract and cache the information using the capability
cache.
When copying the capabilities for a new start of qemu, mask out the
presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type
doesn't support hotpluggable cpus.
Check whether the disable-legacy property is present on the following
devices:
virtio-balloon-pci
virtio-blk-pci
virtio-scsi-pci
virtio-serial-pci
virtio-9p-pci
virtio-net-pci
virtio-rng-pci
virtio-gpu-pci
virtio-input-host-pci
virtio-keyboard-pci
virtio-mouse-pci
virtio-tablet-pci
Assuming that if QEMU knows other virtio devices where this property
is applicable, it will have at least one of these devices.
Added in QEMU by:
commit e266d421490e0ae83044bbebb209b2d3650c0ba6
virtio-pci: add flags to enable/disable legacy/modern
Doing a load, copy, format cycle on all QEMU capabilities XML files
should make sure we don't forget to update virQEMUCapsNewCopy when
adding new elements to QEMU capabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Since its release of 2.4.0 qemu is able to enable System
Management Module in the firmware, or disable it. We should
expose this capability in the XML. Unfortunately, there's no good
way to determine whether the binary we are talking to supports
it. I mean, if qemu's run with real machine type, the smm
attribute can be seen in 'qom-list /machine' output. But it's not
there when qemu's run with -M none. Therefore we're stuck with
version based check.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Check whether QEMU supports -device intel-iommu
Note that the presence of this option does not mean that it's
usable because of a bug in earlier QEMU versions, but it's
better than nothing.
https://bugzilla.redhat.com/show_bug.cgi?id=1235580
Since virQEMUCapsNewForBinaryInternal was introduced,
virQEMUCapsNewForBinary is no longer used outside qemu_capabilities.c.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The virQEMUDriverConfig object contains lists of
loader:nvram pairs to advertise firmwares supported by
by the driver, and qemu_conf.c contains code to populate
the lists, all of which is useful for other drivers too.
To avoid code duplication, introduce a virFirmware object
to encapsulate firmware details and switch the qemu driver
to use it.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
The only QEMU versions that don't have such capability are <0.12,
which we no longer support anyway.
Additionally, this solves the issue of some QEMU binaries being
reported as not having such capability just because they lacked
the {kvm-}pci-assign QMP object.
An iothread for virtio-scsi is a property of the controller. Add a lookup
of the 'virtio-scsi-pci' and 'virtio-scsi-ccw' device properties and parse
the output. For both, support for the iothread was added in qemu 2.4
while support for virtio-scsi in general was added in qemu 1.4.
Modify the various mock capabilities replies (by hand) to reflect the
when virtio-scsi was supported and then specifically when the iothread
property was added. For versions prior to 1.4, use the no device error
return for virtio-scsi. For versions 1.4 to before 2.4, add some data
for virtio-scsi-pci even though it isn't complete we're not looking for
anything specific there anyway. For 2.4 to 2.6, add a more complete reply.
Signed-off-by: John Ferlan <jferlan@redhat.com>
If qemu doesn't support DEVICE_TRAY_MOVED event the code that attempts
to change media would attempt to re-eject the tray even if it wouldn't
be notified when the tray opened. Add a capability bit and skip retrying
for old qemus.
The pxb device is a PCIe expander bus that can be added to any
Q35-based machinetype. A single PCIe port (*not* hotpluggable) is
provided; if more than one device is desired, or if hotplug
support is needed, either a pcie-root-port, or some combination of
pcie-switch-upstream-port and pcie-swith-downstream-ports must be
added to it. It can have a NUMA node number associated with it, as
well as a bus number.
The pxb device is a PCI expander bus that can be added to any
440fx-based machinetype. The PCI bus that is created has 32 standard
PCI slots (hotpluggable). It can have a NUMA node number associated
with it, as well as a bus number.
Add a capability bit for the qemu secret object.
Adjust the 2.6.0-1 caps/replies to add the secret object. For the
.replies it's take from the '{"execute":"qom-list-types"}' output.
Add new function to manage adding the serial device options to the
command line removing that task from the mainline qemuBuildCommandLine.
Using const virDomainDef causes collateral damage in other called APIs
which need to make the similar adjustment
Signed-off-by: John Ferlan <jferlan@redhat.com>
QEMU (somewhere around 2.0) added a new sub-option to the -name flag
-name debug-threads=on.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Honour the <log file='...'/> element in chardevs to output
data to a file. This requires QEMU >= 2.6
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
