Commit Graph

34 Commits

Author SHA1 Message Date
Daniel P. Berrange
4e8993a250 qemu: assume various QEMU 0.10 features are always available
The -sdl and -net ...name=XXX arguments were both introduced
in QEMU 0.10, so the QEMU driver can assume they are always
available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:18 +00:00
Daniel P. Berrange
72edc90a65 qemu: assume -vga is always available
As of QEMU 0.10.0 the -vga argument was introduced, so the
QEMU driver can assume it is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:17 +00:00
Daniel P. Berrange
f81e0d480e qemu: assume -drive format is always available
As of QEMU 0.10.0 the -drive format= parameter was added,
so the QEMU driver can assume it is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:17 +00:00
Daniel P. Berrange
468273a69c qemu: assume -drive cache always uses v2 option names
As of QEMU 0.10.0, the -drive cache option stopped using
the on/off value names, so the QEMU driver can assume
use of the new value names.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:17 +00:00
Daniel P. Berrange
2e90c9daf9 qemu: assume support for all migration protocols except rdma
Since we require QEMU 0.12.0, we can assume that QEMU supports
all of the fd, tcp, unix and exec migration protocols.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:17 +00:00
Daniel P. Berrange
8e5a21ee05 qemu: assume vnet-hdr feature is always available 2015-11-10 10:38:17 +00:00
Daniel P. Berrange
dc7f6c3d30 qemu: assume -uuid is always available
The -uuid arg was added in QEMU 0.10.0, so the QEMU driver can
assume it is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:02 +00:00
Daniel P. Berrange
4588c2ce97 qemu: assume -name is always available
The -name arg was added in QEMU 0.9.1, so the QEMU driver can
assume it is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:02 +00:00
Daniel P. Berrange
f78610038d qemu: assume -drive argument is always available
As of QEMU 0.9.1 the -drive argument can be used to configure
all disks, so the QEMU driver can assume it is always available
and drop support for -hda/-cdrom/etc.

Many of the tests need updating because a great many were
running without CAPS_DRIVE set, so using the -hda legacy
syntax.

Fixing the tests uncovered a bug in the argv -> xml
convertor which failed to handle disk with if=floppy.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:01 +00:00
Daniel P. Berrange
f7ee34114d qemu: assume -no-reboot is always available
The -no-reboot arg was added in QEMU 0.9.0, so the QEMU driver
can now assume it is always present.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:01 +00:00
Daniel P. Berrange
9cd0fe69cd qemu: assume -vnc arg always takes a ':'
As of QEMU 0.9.0 the -vnc option accepts a ':' to separate port
from listen address, so the QEMU driver can assume that support
for listen addresses is always available.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-11-10 10:38:01 +00:00
Andrea Bolognani
fedbb015a9 qemu: Introduce QEMU_CAPS_DEVICE_VIRTIO_NET
This capability can be used to detect whether or not the QEMU
binary supports the virtio-net-* network device.
2015-09-10 09:25:02 +02:00
Andrea Bolognani
fb58318d7f qemu: Introduce QEMU_CAPS_DEVICE_E1000
This capability can be used to detect whether or not the QEMU
binary supports the e1000 network device.
2015-09-10 09:25:01 +02:00
Andrea Bolognani
b8d545a8b8 qemu: Introduce QEMU_CAPS_DEVICE_RTL8139
This capability can be used to detect whether or not the QEMU
binary supports the rtl8139 network device.
2015-09-10 09:25:01 +02:00
Laine Stump
ad1748a1aa qemu: add capabilities bit for device xio3130-downstream
The downstream ports of an x3130-upstream switch can each have one of
these plugged into them (and that is the only place they can be
connected). Each xio3130-downstream provides a single PCIe port that
can have PCI or PCIe devices hotplugged into it. Apparently an entire
set of x3130-upstream + several xio3130-downstreams can be hotplugged
as a unit, but it's not clear to me yet how that would be done, since
qemu only allows attaching a single device at a time.

This device will be used to implement the
"pcie-switch-downstream-port" model of pci controller.
2015-08-09 22:29:25 -04:00
Laine Stump
4cde758808 qemu: add capabilities bit for device x3130-upstream
This is the upstream part of a PCIe switch. It connects to a PCIe port
(but not PCI) on the upstream side, and can have up to 31
xio3130-downstream controllers (but no other types of devices)
connected to its downstream side.

This device will be used to implement the "pcie-switch-upstream-port"
model of pci controller.
2015-08-09 22:02:16 -04:00
Laine Stump
408b100a06 qemu: add capabilities bit for device ioh3420
This is a PCIE "root port". It connects only to a port of the
integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and
provides a single PCIe port that can have PCI or PCIe devices
hotplugged into it.

This device will be used to implement the "pcie-root-port" model of
pci controller.
2015-08-09 21:44:11 -04:00
Michal Privoznik
8e33cb41f3 qemu: Implement pci-serial
https://bugzilla.redhat.com/show_bug.cgi?id=998813

Implementation is pretty straight-forward. Of course, not all qemus
out there supports the device, so new capability is introduced and
checked prior each use of the device.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-05-21 17:49:02 +02:00
Pavel Hrdina
f480a87aa6 caps: introduce new QEMU capability for vgamem_mb device property
Allow setting vgamem size for video devices.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-11-24 22:05:56 +01:00
Maxime Leroy
e3d478eb51 qemu: add capability probing for ivshmem device
Ivshmem is supported by QEMU since 0.13 release.

Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-10-03 22:43:08 +02:00
Pavel Hrdina
da7799d879 Move the FIPS detection from capabilities
We are not detecting the presence of FIPS from QEMU, but from procfs and
that means it's not QEMU capability. It was decided that we will pass
this flag to QEMU even if it's not supported by old QEMU binaries.

This patch also reverts changes done by commit a21cfb0f to
qemucapabilitestest and implements a new test case in qemuxml2argvtest.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-09-19 09:08:23 +02:00
Martin Kletzander
9e1af156af qemu: add capability probing for splash-timeout
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-08-25 14:10:54 +02:00
Peter Krempa
e260a0e60a conf: Add USB sound card support and implement it for qemu 2014-08-08 14:34:20 +02:00
Ján Tomko
f3be5f0c50 Add support for timestamping QEMU logs
QEMU commit 5e2ac51 added a boolean '-msg timestamp=[on|off]'
option, which can enable timestamps on errors:
$ qemu-system-x86_64 -msg timestamp=on zghhdorf
2014-04-09T13:25:46.779484Z qemu-system-x86_64: -msg timestamp=on: could
not open disk image zghhdorf: Could not open 'zghhdorf': No such file or
directory

Enable this timestamp if the QEMU binary supports it.

Add a 'log_timestamp' option to qemu.conf for disabling this behavior.
2014-05-07 10:27:50 +02:00
Laine Stump
17133e3702 qemu: add host-pci-multidomain capability
Quite a long time ago, (apparently between qemu 0.12 and 0.13) qemu
quietly began supporting the optional specification of a domain in the
host-side address of all pci passthrough commands (by simply
prepending it to the bus:slot.function format, as
"dddd:bb:ss.f"). Since machines with multiple PCI domains are very
rare, this never came up in practice, so libvirt was never updated to
support it.

This patch takes the first step to supporting specification of a non-0
domain in the host-side address of PCI devices being assigned to a
domain, by adding a capability bit to indicate support
"QEMU_CAPS_HOST_PCI_MULTIDOMAIN", and detect it. Since this support
was added in a version prior to the minimum version required for
QMP-style capabilities detection, the capability is always enabled for
any qemu that uses QMP for capabilities detection. For older qemus,
the only clue that a domain can be specified in the host pci address
is the presence of the string "[seg:]" in the help string for
-pcidevice. (Ironically, libvirt will not be modified to support
specification of domain for -pcidevice, since any qemu new enough for
us to care about also supports "-device pci-assign" or "-device
vfio-pci", which are greatly preferred).
2014-05-06 14:32:33 +03:00
Li Zhang
f5ffd45f4c qemu: Add USB keyboard capability
Add USB keyboard capability probing and test cases.

Signed-off-by: Li Zhang <zhlcindy@linux.vnet.ibm.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
2014-02-19 09:16:31 +01:00
Martin Kletzander
d27e6bc40f qemu: introduce spiceport chardev backend
Add a new backend for any character device.  This backend uses channel
in spice connection.  This channel is similar to spicevmc, but
all-purpose in contrast to spicevmc.

Apart from spicevmc, spiceport-backed chardev will not be formatted
into the command-line if there is no spice to use (with test for that
as well).  For this I moved the def->graphics counting to the start
of the function so its results can be used in rest of the code even in
the future.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-02-11 13:43:55 +01:00
Francesco Romani
19bbc81276 spice: detect if qemu can disable file transfer
spice-server offers an API to disable file transfer messages
on the agent channel between the client and the guest.
This is supported in qemu through the disable-agent-file-xfer option.

This patch detects if QEMU supports this option, and add
a capability if does.

Signed-off-by: Francesco Romani <fromani@redhat.com>
2014-01-21 11:35:40 +01:00
Eric Blake
a21cfb0f48 qemu: ask for -enable-fips when FIPS is required
On a system that is enforcing FIPS, most libraries honor the
current mode by default.  Qemu, on the other hand, refused to
honor FIPS mode unless you add the '-enable-fips' command
line option; worse, this option is not discoverable via QMP,
and is only present on binaries built for Linux.  So, if we
detect FIPS mode, then we unconditionally ask for FIPS; either
qemu is new enough to have the option and then correctly
cripple insecure VNC passwords, or it is so old that we are
correctly avoiding a FIPS violation by preventing qemu from
starting.  Meanwhile, if we don't detect FIPS mode, then
omitting the argument is safe whether the qemu has the option
(but it would do nothing because FIPS is disabled) or whether
qemu lacks the option (including in the case where we are not
running on Linux).

The testsuite was a bit interesting: we don't want our test
to depend on whether it is being run in FIPS mode, so I had
to tweak things to set the capability bit outside of our
normal interaction with capability parsing.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035474

* src/qemu/qemu_capabilities.h (QEMU_CAPS_ENABLE_FIPS): New bit.
* src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Conditionally
set capability according to detection of FIPS mode.
* src/qemu/qemu_command.c (qemuBuildCommandLine): Use it.
* tests/qemucapabilitiestest.c (testQemuCaps): Conditionally set
capability to test expected output.
* tests/qemucapabilitiesdata/caps_1.2.2-1.caps: Update list.
* tests/qemucapabilitiesdata/caps_1.6.0-1.caps: Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-12-18 07:05:29 -07:00
Martin Kletzander
15275f2edb qemu: check for reboot-timeout on monitor
The support for <boot rebootTimeout="12345"/> was added before we were
checking for qemu command line options in QMP, so we haven't properly
adapted virQEMUCaps when using it and thus we report unsupported
option with new enough qemu.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1042690

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2013-12-13 15:20:09 +01:00
Hu Tao
4d18758df8 qemu: add support for -device pvpanic
Map the new <panic> device in XML to the '-device pvpanic' command
line of qemu.  Clients can then couple the <panic> device and the
<on_crash> directive to control behavior when the guest reports
a panic to qemu.

Signed-off-by: Hu Tao <hutao@cn.fujitsu.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-12-13 05:53:33 -07:00
Laine Stump
96fddee322 qemu: add "-boot strict" to commandline whenever possible
This resolves:

  https://bugzilla.redhat.com/show_bug.cgi?id=888635

(which was already closed as CANTFIX because the qemu "-boot strict"
commandline option wasn't available at the time).

Problem: you couldn't have a domain that used PXE to boot, but also
had an un-bootable disk device *even if that disk wasn't listed in the
boot order*, because if PXE timed out (e.g. due to the bridge
forwarding delay), the BIOS would move on to the next target, which
would be the unbootable disk device (again - even though it wasn't
given a boot order), and get stuck at a "BOOT DISK FAILURE, PRESS ANY
KEY" message until a user intervened.

The solution available since sometime around QEMU 1.5, is to add
"-boot strict=on" to *every* qemu command. When this is done, if any
devices have a boot order specified, then QEMU will *only* attempt to
boot from those devices that have an explicit boot order, ignoring the
rest.
2013-12-03 11:58:26 +02:00
Ján Tomko
1569fa14d8 qemu: don't use deprecated -no-kvm-pit-reinjection
Since qemu-kvm 1.1 [1] (since 1.3. in upstream QEMU [2])
'-no-kvm-pit-reinjection' has been deprecated.
Use -global kvm-pit.lost_tick_policy=discard instead.

https://bugzilla.redhat.com/show_bug.cgi?id=978719

[1] http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39
[2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f
2013-11-05 16:04:06 +01:00
Michal Privoznik
3e17d7956f qemucapabilitiesdata: Add qemu-1.6.0 data
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-03 15:52:06 +02:00