- 06 5月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 03 5月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
Reports whether we support -device nec-usb-xhci,p3=XXX value, which has been available since qemu 1.3.0
-
- 02 5月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
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.
-
- 15 4月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
The flag is now unused and all qemus supported by libvirt already support it.
-
- 11 3月, 2016 1 次提交
-
-
由 Marc-André Lureau 提交于
QEMU (somewhere around 2.0) added a new sub-option to the -name flag -name debug-threads=on. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 01 3月, 2016 1 次提交
-
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 12 1月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
This capability tells if qemu is capable of vserport_change events. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 11月, 2015 11 次提交
-
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
As of QEMU 0.10.0 the -vga argument was introduced, so the QEMU driver can assume it is always available. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
The -uuid arg was added in QEMU 0.10.0, so the QEMU driver can assume it is always available. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The -name arg was added in QEMU 0.9.1, so the QEMU driver can assume it is always available. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
- 10 9月, 2015 3 次提交
-
-
由 Andrea Bolognani 提交于
This capability can be used to detect whether or not the QEMU binary supports the virtio-net-* network device.
-
由 Andrea Bolognani 提交于
This capability can be used to detect whether or not the QEMU binary supports the e1000 network device.
-
由 Andrea Bolognani 提交于
This capability can be used to detect whether or not the QEMU binary supports the rtl8139 network device.
-
- 10 8月, 2015 3 次提交
-
-
由 Laine Stump 提交于
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.
-
由 Laine Stump 提交于
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.
-
由 Laine Stump 提交于
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.
-
- 21 5月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
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: NMichal Privoznik <mprivozn@redhat.com>
-
- 21 2月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
The pc-dimm device represents a RAM memory module.
-
- 25 11月, 2014 1 次提交
-
-
由 Pavel Hrdina 提交于
Allow setting vgamem size for video devices. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1076098Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 10 11月, 2014 1 次提交
-
-
由 Matthias Gatto 提交于
Add the capability to detect if the qemu binary have the capability to use bps_max and friends Add a value in the enum virQEMUCapsFlags for the qemu capability. Set it with virQEMUCapsSet if the binary suport bps_max and they friends. Signed-off-by: NMatthias Gatto <matthias.gatto@outscale.com>
-
- 04 10月, 2014 1 次提交
-
-
由 Maxime Leroy 提交于
Ivshmem is supported by QEMU since 0.13 release. Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 23 9月, 2014 1 次提交
-
-
由 Jiri Denemark 提交于
-
- 19 9月, 2014 1 次提交
-
-
由 Pavel Hrdina 提交于
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=1135431Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 25 8月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 08 8月, 2014 1 次提交
-
-
由 Peter Krempa 提交于
-
- 07 5月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
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.
-
- 06 5月, 2014 1 次提交
-
-
由 Laine Stump 提交于
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).
-
- 19 2月, 2014 1 次提交
-
-
由 Li Zhang 提交于
Add USB keyboard capability probing and test cases. Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 11 2月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
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: NMartin Kletzander <mkletzan@redhat.com>
-
- 21 1月, 2014 1 次提交
-
-
由 Francesco Romani 提交于
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: NFrancesco Romani <fromani@redhat.com>
-
- 18 12月, 2013 1 次提交
-
-
由 Eric Blake 提交于
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: NEric Blake <eblake@redhat.com>
-
- 13 12月, 2013 1 次提交
-
-
由 Martin Kletzander 提交于
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=1042690Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-