External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-27 08:05:24 +00:00
Code Issues Packages Projects Releases Wiki Activity
105b51f42e
libvirt/tests/qemucapabilitiesdata/caps_1.5.3-1.caps

141 lines
4.3 KiB
Plaintext
Raw Normal View History

tests: Introduce qemucapabilitiestest This test is there to ensure that our capabilities detection code isn't broken somehow. How to gather test data: Firstly, the data is split into two separate files. The former (with suffix .replies) contains all the qemu replies. This is very fragile as introducing a new device can mean yet another monitor command and hence edit of this file in the future. But there's no better way of doing this. To get this data simply turn on debug logs and copy all the QEMU_MONITOR_IO_PROCESS lines. But be careful to not copy incomplete ones (yeah, we report some incomplete lines too). Long story short, at the libvirtd startup, a dummy qemu is spawn to get all the capabilities. The latter (with suffix .caps) contains capabilities XML. Just start a domain and copy the corresponding part from its state XML file. Including <qemuCaps> tag. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:44:41 +00:00
<qemuCaps>
<flag name='mem-path'/>
<flag name='drive-serial'/>
<flag name='chardev'/>
<flag name='enable-kvm'/>
<flag name='monitor-json'/>
<flag name='balloon'/>
<flag name='device'/>
<flag name='sdl'/>
<flag name='smp-topology'/>
<flag name='netdev'/>
<flag name='rtc'/>
<flag name='vhost-net'/>
<flag name='no-hpet'/>
<flag name='no-kvm-pit'/>
<flag name='pci-configfd'/>
<flag name='nodefconfig'/>
<flag name='boot-menu'/>
<flag name='fsdev'/>
<flag name='name-process'/>
<flag name='drive-readonly'/>
<flag name='smbios-type'/>
<flag name='vga-qxl'/>
<flag name='spice'/>
<flag name='vga-none'/>
<flag name='boot-index'/>
<flag name='hda-duplex'/>
<flag name='drive-aio'/>
<flag name='pci-multibus'/>
<flag name='pci-bootindex'/>
<flag name='ccid-passthru'/>
<flag name='chardev-spicevmc'/>
<flag name='virtio-tx-alg'/>
<flag name='device-qxl-vga'/>
<flag name='pci-multifunction'/>
<flag name='virtio-blk-pci.ioeventfd'/>
<flag name='sga'/>
<flag name='virtio-blk-pci.event_idx'/>
<flag name='virtio-net-pci.event_idx'/>
<flag name='cache-directsync'/>
<flag name='piix3-usb-uhci'/>
<flag name='piix4-usb-uhci'/>
<flag name='usb-ehci'/>
<flag name='ich9-usb-ehci1'/>
<flag name='vt82c686b-usb-uhci'/>
<flag name='pci-ohci'/>
<flag name='usb-hub'/>
<flag name='no-shutdown'/>
<flag name='cache-unsafe'/>
<flag name='rombar'/>
<flag name='ich9-ahci'/>
<flag name='no-acpi'/>
<flag name='fsdev-readonly'/>
<flag name='virtio-blk-pci.scsi'/>
<flag name='blk-sg-io'/>
<flag name='drive-copy-on-read'/>
<flag name='cpu-host'/>
<flag name='fsdev-writeout'/>
<flag name='drive-iotune'/>
<flag name='system_wakeup'/>
<flag name='scsi-disk.channel'/>
<flag name='scsi-block'/>
<flag name='transaction'/>
<flag name='block-job-async'/>
<flag name='scsi-cd'/>
<flag name='ide-cd'/>
<flag name='no-user-config'/>
<flag name='hda-micro'/>
<flag name='dump-guest-memory'/>
<flag name='nec-usb-xhci'/>
<flag name='balloon-event'/>
<flag name='bridge'/>
<flag name='lsi'/>
<flag name='virtio-scsi-pci'/>
<flag name='blockio'/>
<flag name='disable-s3'/>
<flag name='disable-s4'/>
<flag name='ide-drive.wwn'/>
<flag name='scsi-disk.wwn'/>
<flag name='seccomp-sandbox'/>
<flag name='dump-guest-core'/>
<flag name='seamless-migration'/>
<flag name='block-commit'/>
<flag name='vnc'/>
<flag name='drive-mirror'/>
<flag name='usb-host.bootindex'/>
<flag name='blockdev-snapshot-sync'/>
<flag name='qxl'/>
<flag name='VGA'/>
<flag name='cirrus-vga'/>
<flag name='vmware-svga'/>
<flag name='usb-serial'/>
<flag name='usb-net'/>
<flag name='add-fd'/>
<flag name='nbd-server'/>
<flag name='virtio-rng'/>
<flag name='rng-random'/>
<flag name='rng-egd'/>
<flag name='dtb'/>
<flag name='megasas'/>
<flag name='ipv6-migration'/>
<flag name='machine-opt'/>
<flag name='machine-usb-opt'/>
<flag name='pci-bridge'/>
<flag name='vfio-pci'/>
<flag name='vfio-pci.bootindex'/>
<flag name='scsi-generic'/>
<flag name='scsi-generic.bootindex'/>
<flag name='mem-merge'/>
<flag name='vnc-websocket'/>
<flag name='drive-discard'/>
<flag name='mlock'/>
<flag name='vnc-share-policy'/>
<flag name='device-del-event'/>
<flag name='dmi-to-pci-bridge'/>
<flag name='usb-storage'/>
<flag name='usb-storage.removable'/>
<flag name='ich9-intel-hda'/>
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-07-01 16:28:50 +00:00
<flag name='kvm-pit-lost-tick-policy'/>
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-02 12:07:12 +00:00
<flag name='boot-strict'/>
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-09 09:11:15 +00:00
<flag name='pvpanic'/>
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 13:51:24 +00:00
<flag name='reboot-timeout'/>
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-01-30 11:19:12 +00:00
<flag name='spiceport'/>
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-17 10:17:55 +00:00
<flag name='usb-kbd'/>
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-04-29 15:11:45 +00:00
<flag name='host-pci-multidomain'/>
conf: Add USB sound card support and implement it for qemu
2014-07-24 15:32:31 +00:00
<flag name='usb-audio'/>
qemu: add capability probing for splash-timeout Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-08-22 11:42:46 +00:00
<flag name='splash-timeout'/>
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-08-22 10:47:02 +00:00
<flag name='ivshmem'/>
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-12 12:58:33 +00:00
<flag name='VGA.vgamem_mb'/>
<flag name='vmware-svga.vgamem_mb'/>
<flag name='qxl.vgamem_mb'/>
<flag name='qxl-vga.vgamem_mb'/>
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-06 15:50:03 +00:00
<flag name='pci-serial'/>
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-06-17 17:13:28 +00:00
<flag name='ioh3420'/>
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-06-16 18:54:21 +00:00
<flag name='x3130-upstream'/>
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-06-17 18:24:29 +00:00
<flag name='xio3130-downstream'/>
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-04 14:23:46 +00:00
<flag name='rtl8139'/>
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-04 14:40:37 +00:00
<flag name='e1000'/>
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-01 12:38:19 +00:00
<flag name='virtio-net'/>
tests: Introduce qemucapabilitiestest This test is there to ensure that our capabilities detection code isn't broken somehow. How to gather test data: Firstly, the data is split into two separate files. The former (with suffix .replies) contains all the qemu replies. This is very fragile as introducing a new device can mean yet another monitor command and hence edit of this file in the future. But there's no better way of doing this. To get this data simply turn on debug logs and copy all the QEMU_MONITOR_IO_PROCESS lines. But be careful to not copy incomplete ones (yeah, we report some incomplete lines too). Long story short, at the libvirtd startup, a dummy qemu is spawn to get all the capabilities. The latter (with suffix .caps) contains capabilities XML. Just start a domain and copy the corresponding part from its state XML file. Including <qemuCaps> tag. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-09-19 11:44:41 +00:00
</qemuCaps>
Reference in New Issue Copy Permalink