shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-23 21:34:54 +03:00
Code Releases Activity
2089a801ba
libvirt/tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml

887 lines
44 KiB
XML
Raw Normal View History

tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<qemuCaps>
<qemuctime>0</qemuctime>
<selfctime>0</selfctime>
<selfvers>0</selfvers>
<usedQMP/>
<flag name='kvm'/>
<flag name='no-hpet'/>
<flag name='no-kvm-pit'/>
<flag name='pci-configfd'/>
<flag name='spice'/>
<flag name='boot-index'/>
<flag name='hda-duplex'/>
<flag name='pci-bootindex'/>
<flag name='ccid-emulated'/>
<flag name='ccid-passthru'/>
<flag name='virtio-tx-alg'/>
<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='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-redir'/>
<flag name='usb-hub'/>
<flag name='ich9-ahci'/>
<flag name='no-acpi'/>
<flag name='virtio-blk-pci.scsi'/>
<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='hda-micro'/>
<flag name='dump-guest-memory'/>
<flag name='nec-usb-xhci'/>
<flag name='balloon-event'/>
<flag name='lsi'/>
<flag name='virtio-scsi-pci'/>
<flag name='blockio'/>
<flag name='disable-s3'/>
<flag name='disable-s4'/>
<flag name='usb-redir.filter'/>
<flag name='ide-drive.wwn'/>
<flag name='scsi-disk.wwn'/>
<flag name='reboot-timeout'/>
<flag name='dump-guest-core'/>
<flag name='seamless-migration'/>
<flag name='block-commit'/>
<flag name='vnc'/>
<flag name='drive-mirror'/>
<flag name='usb-redir.bootindex'/>
<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='device-video-primary'/>
<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='megasas'/>
<flag name='ipv6-migration'/>
<flag name='machine-opt'/>
<flag name='machine-usb-opt'/>
<flag name='tpm-passthrough'/>
<flag name='tpm-tis'/>
<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='i440fx-pci-hole64-size'/>
<flag name='q35-pci-hole64-size'/>
<flag name='usb-storage'/>
<flag name='usb-storage.removable'/>
<flag name='virtio-mmio'/>
<flag name='ich9-intel-hda'/>
<flag name='kvm-pit-lost-tick-policy'/>
<flag name='boot-strict'/>
<flag name='pvpanic'/>
<flag name='spice-file-xfer-disable'/>
<flag name='spiceport'/>
<flag name='usb-kbd'/>
<flag name='host-pci-multidomain'/>
<flag name='msg-timestamp'/>
<flag name='active-commit'/>
<flag name='change-backing-file'/>
<flag name='memory-backend-ram'/>
<flag name='numa'/>
<flag name='memory-backend-file'/>
<flag name='usb-audio'/>
<flag name='rtc-reset-reinjection'/>
<flag name='splash-timeout'/>
<flag name='iothread'/>
<flag name='migrate-rdma'/>
<flag name='ivshmem'/>
<flag name='drive-iotune-max'/>
<flag name='VGA.vgamem_mb'/>
<flag name='vmware-svga.vgamem_mb'/>
<flag name='qxl.vgamem_mb'/>
<flag name='pc-dimm'/>
<flag name='machine-vmport-opt'/>
<flag name='aes-key-wrap'/>
<flag name='dea-key-wrap'/>
<flag name='pci-serial'/>
<flag name='vhost-user-multiqueue'/>
<flag name='migration-event'/>
<flag name='ioh3420'/>
<flag name='x3130-upstream'/>
<flag name='xio3130-downstream'/>
<flag name='rtl8139'/>
<flag name='e1000'/>
<flag name='virtio-net'/>
<flag name='gic-version'/>
<flag name='incoming-defer'/>
<flag name='virtio-gpu'/>
<flag name='virtio-gpu.virgl'/>
<flag name='virtio-keyboard'/>
<flag name='virtio-mouse'/>
<flag name='virtio-tablet'/>
<flag name='virtio-input-host'/>
<flag name='chardev-file-append'/>
<flag name='ich9-disable-s3'/>
<flag name='ich9-disable-s4'/>
<flag name='vserport-change-event'/>
<flag name='virtio-balloon-pci.deflate-on-oom'/>
<flag name='mptsas1068'/>
<flag name='spice-gl'/>
<flag name='qxl.vram64_size_mb'/>
<flag name='chardev-logfile'/>
<flag name='debug-threads'/>
<flag name='secret'/>
<flag name='pxb'/>
<flag name='pxb-pcie'/>
<flag name='device-tray-moved-event'/>
<flag name='nec-usb-xhci-ports'/>
<flag name='virtio-scsi-pci.iothread'/>
<flag name='name-guest'/>
<flag name='qxl.max_outputs'/>
<flag name='spice-unix'/>
<flag name='drive-detect-zeroes'/>
<flag name='tls-creds-x509'/>
<flag name='display'/>
<flag name='intel-iommu'/>
<flag name='smm'/>
<flag name='virtio-pci-disable-legacy'/>
<flag name='query-hotpluggable-cpus'/>
<flag name='virtio-net.rx_queue_size'/>
<flag name='virtio-vga'/>
<flag name='drive-iotune-max-length'/>
<flag name='ivshmem-plain'/>
<flag name='ivshmem-doorbell'/>
<flag name='query-qmp-schema'/>
<flag name='gluster.debug_level'/>
<flag name='vhost-scsi'/>
<flag name='drive-iotune-group'/>
qemucapstest: Update test data for QEMU 2.9.0 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 18:10:22 +03:00
<flag name='query-cpu-model-expansion'/>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<flag name='virtio-net.host_mtu'/>
tests: update QEMU 2.9.0 caps data Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-03-21 14:45:00 +03:00
<flag name='spice-rendernode'/>
tests: update QEMU 2.9.0 caps data to final version Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-26 20:19:50 +03:00
<flag name='nvdimm'/>
qemu: Add support for generic PCIe Root Ports QEMU 2.9 introduces the pcie-root-port device, which is a generic version of the existing ioh3420 device. Make the new device available to libvirt users.
2017-01-16 15:28:20 +03:00
<flag name='pcie-root-port'/>
qemu: skip QMP probing of CPU definitions when missing This unbreaks emulators that don't support this command such as qemu-system-mips*. Reference: http://bugs.debian.org/854125
2017-03-16 11:19:02 +03:00
<flag name='query-cpu-definitions'/>
qemu: monitor: Add support for BLOCK_WRITE_THRESHOLD event The event is fired when a given block backend node (identified by the node name) experiences a write beyond the bound set via block-set-write-threshold QMP command. This wires up the monitor code to extract the data and allow us receiving the events and the capability.
2017-02-22 18:52:22 +03:00
<flag name='block-write-threshold'/>
qemu: capabilities: add capability for query-named-block-nodes qmp cmd
2017-03-15 19:21:48 +03:00
<flag name='query-named-block-nodes'/>
qemu: Add support for guest CPU cache This patch maps /domain/cpu/cache element into -cpu parameters: - <cache mode='passthrough'/> is translated to host-cache-info=on - <cache level='3' mode='emulate'/> is transformed into l3-cache=on - <cache mode='disable'/> is turned in host-cache-info=off,l3-cache=off Any other <cache> element is forbidden. The tricky part is detecting whether QEMU supports the CPU properties. The 'host-cache-info' property is introduced in v2.4.0-1389-ge265e3e480, earlier QEMU releases enabled host-cache-info by default and had no way to disable it. If the property is present, it defaults to 'off' for any QEMU until at least 2.9.0. The 'l3-cache' property was introduced later by v2.7.0-200-g14c985cffa. Earlier versions worked as if l3-cache=off was passed. For any QEMU until at least 2.9.0 l3-cache is 'off' by default. QEMU 2.9.0 was the first release which supports probing both properties by running device-list-properties with typename=host-x86_64-cpu. Older QEMU releases did not support device-list-properties command for CPU devices. Thus we can't really rely on probing them and we can just use query-cpu-model-expansion QMP command as a witness. Because the cache property probing is only reliable for QEMU >= 2.9.0 when both are already supported for quite a few releases, we let QEMU report an error if a specific cache mode is explicitly requested. The other mode (or both if a user requested CPU cache to be disabled) is explicitly turned off for QEMU >= 2.9.0 to avoid any surprises in case the QEMU defaults change. Any older QEMU already turns them off so not doing so explicitly does not make any harm. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-04-25 20:07:19 +03:00
<flag name='cpu-cache'/>
qemu: introduce QEMU_CAPS_DEVICE_QEMU_XHCI Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Acked-by: Andrea Bolognani <abologna@redhat.com>
2017-04-28 11:44:03 +03:00
<flag name='qemu-xhci'/>
qemu: format kernel_irqchip on the command line Add kernel_irqchip=split/on to the QEMU command line and a capability that looks for it in query-command-line-options output. For the 'split' option, use a version check since it cannot be reasonably probed. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-03-17 10:26:49 +03:00
<flag name='kernel-irqchip'/>
<flag name='kernel-irqchip.split'/>
qemu: format intel-iommu,intremap on the command line https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-05-03 16:23:12 +03:00
<flag name='intel-iommu.intremap'/>
qemu: format caching-mode on iommu command line Format the caching-mode option for the intel-iommu device, based on its <driver caching> attribute value. https://bugzilla.redhat.com/show_bug.cgi?id=1427005
2017-03-17 10:28:04 +03:00
<flag name='intel-iommu.caching-mode'/>
qemu: format eim on intel-iommu command line This option turns on extended interrupt mode, which allows more than 255 vCPUs. https://bugzilla.redhat.com/show_bug.cgi?id=1451282 Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2017-05-18 11:48:03 +03:00
<flag name='intel-iommu.eim'/>
qemu: format device-iotlb on intel-iommu command line Format the device-iotlb attribute. https://bugzilla.redhat.com/show_bug.cgi?id=1283251 Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-05-03 18:18:47 +03:00
<flag name='intel-iommu.device-iotlb'/>
qemu: format virtio-related options on the command line Format iommu_platform= and ats= for virtio devices. https://bugzilla.redhat.com/show_bug.cgi?id=1283251 Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-05-24 18:09:12 +03:00
<flag name='virtio.iommu_platform'/>
<flag name='virtio.ats'/>
qemu: capabilities: introduce QEMU_CAPS_VNC_MULTI_SERVERS Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-07-21 19:44:14 +03:00
<flag name='vnc-multi-servers'/>
qemu: introduce QEMU_CAPS_CHARDEV_RECONNECT Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-08-09 16:06:40 +03:00
<flag name='chardev-reconnect'/>
qemu: Add capabilities for virtio-vga/gpu's max_outputs= parameter Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2017-08-23 15:06:17 +03:00
<flag name='virtio-gpu.max_outputs'/>
qemucapstest: Update test data for 'num-queues' property of virtio-blk Signed-off-by: Lin Ma <lma@suse.com>
2017-09-30 20:15:35 +03:00
<flag name='virtio-blk.num-queues'/>
qemu: caps: Add capability for 'share-rw' disk option 'share-rw' for the disk device configures qemu to allow concurrent access to the backing storage. The capability is checked in various supported disk frontend buses since it does not make sense to partially backport it.
2017-11-15 17:02:58 +03:00
<flag name='disk-share-rw'/>
qemu: Get capabilities to use iscsi password-secret argument Detect the capability via the query-qmp-schema for blockdev-add to find the 'password-secret' parameter that will allow the iSCSI code to use the master secret object to encrypt the secret for an and only need to provide the object id of the secret on the command line thus obsfuscating the passphrase.
2017-09-01 22:09:29 +03:00
<flag name='iscsi.password-secret'/>
qemu: Add QEMU_CAPS_DEVICE_ISA_SERIAL All serial devices shoule have an associated capability. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-11-26 19:19:46 +03:00
<flag name='isa-serial'/>
qemu: Add dump completed event to the capabilities Add the DUMP_COMPLETED check to the capabilities. This is the mechanism used to determine whether the dump-guest-memory command can support the "-detach" option and thus be able to wait on the event and allow for a query of the progress of the dump. Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2017-11-17 16:46:27 +03:00
<flag name='dump-completed'/>
tests: update QEMU 2.9.0 caps data to final version Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-26 20:19:50 +03:00
<version>2009000</version>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<kvmVersion>0</kvmVersion>
qemu: Take full advantage of conditional device property probing Commit 4ae59411fa3f introduced the ability to make probing for device properties conditional on a capability being set, but didn't extend the use of this feature to existing devices. This commit does the last bit of work, which results in a lot of pointless QMP chatter no longer happening and our test suite shrinking a fair bit. Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2018-03-06 15:49:39 +03:00
<microcodeVersion>320947</microcodeVersion>
tests: update QEMU 2.9.0 caps data to final version Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-26 20:19:50 +03:00
<package> (v2.9.0)</package>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<arch>x86_64</arch>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<hostCPU type='kvm' model='base' migratability='yes'>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='phys-bits' type='number' value='0'/>
<property name='core-id' type='number' value='-1'/>
<property name='xlevel' type='number' value='2147483656'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='cmov' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='ia64' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='aes' type='boolean' value='true' migratable='yes'/>
<property name='mmx' type='boolean' value='true' migratable='yes'/>
<property name='arat' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='rdpid' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='pause-filter' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xsavec' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='osxsave' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='tsc-frequency' type='number' value='0'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xd' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-vendor-id' type='string' value=''/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='kvm-asyncpf' type='boolean' value='true' migratable='yes'/>
<property name='kvm_asyncpf' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='perfctr_core' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='perfctr-core' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='mpx' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='avx512cd' type='boolean' value='false'/>
<property name='decodeassists' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='pbe' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='sse4_1' type='boolean' value='true' migratable='yes'/>
<property name='sse4.1' type='boolean' value='true' migratable='yes'/>
<property name='sse4-1' type='boolean' value='true' migratable='yes'/>
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:01:30 +03:00
<property name='family' type='number' value='6'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='vmware-cpuid-freq' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='avx512f' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='xcrypt' type='boolean' value='false'/>
<property name='hv-runtime' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='msr' type='boolean' value='true' migratable='yes'/>
<property name='mce' type='boolean' value='true' migratable='yes'/>
<property name='mca' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='thread-id' type='number' value='-1'/>
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:01:30 +03:00
<property name='min-level' type='number' value='13'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xgetbv1' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='cid' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-relaxed' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='fxsr' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='ds' type='boolean' value='false'/>
<property name='hv-crash' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xsaveopt' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='xtpr' type='boolean' value='false'/>
<property name='avx512-vpopcntdq' type='boolean' value='false'/>
<property name='phe' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='avx512vl' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='extapic' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='3dnowprefetch' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='cr8legacy' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='cpuid-0xb' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='xcrypt-en' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='kvm_pv_eoi' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='apic-id' type='number' value='4294967295'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='pn' type='boolean' value='false'/>
<property name='dca' type='boolean' value='false'/>
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:01:30 +03:00
<property name='vendor' type='string' value='GenuineIntel'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='pku' type='boolean' value='false'/>
<property name='smx' type='boolean' value='false'/>
<property name='cmp-legacy' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='cmp_legacy' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='avx512-4fmaps' type='boolean' value='false'/>
<property name='vmcb-clean' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='vmcb_clean' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='3dnowext' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='hle' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='npt' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='memory' type='string' value='/machine/unattached/system[0]'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='clwb' type='boolean' value='false'/>
<property name='lbrv' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='adx' type='boolean' value='true' migratable='yes'/>
<property name='ss' type='boolean' value='true' migratable='yes'/>
<property name='pni' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='svm_lock' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='svm-lock' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='smep' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='pfthreshold' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='smap' type='boolean' value='true' migratable='yes'/>
<property name='x2apic' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='avx512vbmi' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-stimer' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='i64' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='flushbyasid' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='f16c' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='ace2-en' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='pat' type='boolean' value='true' migratable='yes'/>
<property name='pae' type='boolean' value='true' migratable='yes'/>
<property name='sse' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='phe-en' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='kvm-nopiodelay' type='boolean' value='true' migratable='yes'/>
<property name='kvm_nopiodelay' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='tm' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='kvmclock-stable-bit' type='boolean' value='true' migratable='yes'/>
<property name='hypervisor' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='socket-id' type='number' value='-1'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='pcommit' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='syscall' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='level' type='number' value='13'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='avx512dq' type='boolean' value='false'/>
<property name='svm' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='full-cpuid-auto-level' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-reset' type='boolean' value='false'/>
qemu: Check non-migratable host CPU features CPU features which change their value from disabled to enabled between two calls to query-cpu-model-expansion (the first with no extra properties set and the second with 'migratable' property set to false) can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo. Since the code consuming qemuMonitorCPUModelInfo currently ignores the migratable flag, this change is effectively changing the CPU model advertised in domain capabilities to contain all features (even those which block migration). And this matches what we do for QEMU older than 2.9.0, when we detect all CPUID bits ourselves without asking QEMU. As a result of this change <cpu mode='host-model'> <feature name='invtsc' policy='require'/> </cpu> will work with all QEMU versions. Such CPU definition would be forbidden with QEMU >= 2.9.0 without this patch. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 12:00:32 +03:00
<property name='invtsc' type='boolean' value='true' migratable='no'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='sse3' type='boolean' value='true' migratable='yes'/>
<property name='sse2' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='est' type='boolean' value='false'/>
<property name='avx512ifma' type='boolean' value='false'/>
<property name='tm2' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='kvm-pv-eoi' type='boolean' value='true' migratable='yes'/>
<property name='cx8' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='kvm-mmu' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='kvm_mmu' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='sse4_2' type='boolean' value='true' migratable='yes'/>
<property name='sse4.2' type='boolean' value='true' migratable='yes'/>
<property name='sse4-2' type='boolean' value='true' migratable='yes'/>
<property name='pge' type='boolean' value='true' migratable='yes'/>
<property name='fill-mtrr-mask' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='pdcm' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='nodeid_msr' type='boolean' value='false'/>
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:01:30 +03:00
<property name='model' type='number' value='94'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='movbe' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='nrip-save' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='nrip_save' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='sse4a' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='ssse3' type='boolean' value='true' migratable='yes'/>
<property name='kvm_pv_unhalt' type='boolean' value='true' migratable='yes'/>
<property name='invpcid' type='boolean' value='true' migratable='yes'/>
<property name='pdpe1gb' type='boolean' value='true' migratable='yes'/>
<property name='tsc-deadline' type='boolean' value='true' migratable='yes'/>
<property name='fma' type='boolean' value='true' migratable='yes'/>
<property name='cx16' type='boolean' value='true' migratable='yes'/>
<property name='de' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='enforce' type='boolean' value='false'/>
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:01:30 +03:00
<property name='stepping' type='number' value='3'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xsave' type='boolean' value='true' migratable='yes'/>
<property name='clflush' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='skinit' type='boolean' value='false'/>
<property name='tce' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='tsc' type='boolean' value='true' migratable='yes'/>
<property name='fpu' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='ds-cpl' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='ds_cpl' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='ibs' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='host-phys-bits' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='fma4' type='boolean' value='false'/>
<property name='la57' type='boolean' value='false'/>
<property name='osvw' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='check' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-spinlocks' type='number' value='-1'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='pmm' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='apic' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='pmu' type='boolean' value='false'/>
<property name='min-xlevel2' type='number' value='0'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='tsc-adjust' type='boolean' value='true' migratable='yes'/>
<property name='tsc_adjust' type='boolean' value='true' migratable='yes'/>
<property name='kvm-steal-time' type='boolean' value='true' migratable='yes'/>
<property name='kvm_steal_time' type='boolean' value='true' migratable='yes'/>
<property name='kvmclock' type='boolean' value='true' migratable='yes'/>
<property name='l3-cache' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='lwp' type='boolean' value='false'/>
<property name='xop' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='avx' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='ospke' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='ace2' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='acpi' type='boolean' value='false'/>
<property name='avx512bw' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-vapic' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='fsgsbase' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='ht' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='nx' type='boolean' value='true' migratable='yes'/>
<property name='pclmulqdq' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='mmxext' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='popcnt' type='boolean' value='true' migratable='yes'/>
<property name='xsaves' type='boolean' value='true' migratable='yes'/>
<property name='lm' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='umip' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='avx2' type='boolean' value='true' migratable='yes'/>
<property name='pse' type='boolean' value='true' migratable='yes'/>
<property name='sep' type='boolean' value='true' migratable='yes'/>
<property name='pclmuldq' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='nodeid-msr' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='kvm' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='misalignsse' type='boolean' value='false'/>
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:01:30 +03:00
<property name='min-xlevel' type='number' value='2147483656'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='bmi2' type='boolean' value='true' migratable='yes'/>
<property name='bmi1' type='boolean' value='true' migratable='yes'/>
<property name='kvm-pv-unhalt' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='realized' type='boolean' value='false'/>
<property name='tsc_scale' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='tsc-scale' type='boolean' value='false'/>
<property name='topoext' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-vpindex' type='boolean' value='false'/>
<property name='xlevel2' type='number' value='0'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='clflushopt' type='boolean' value='true' migratable='yes'/>
tests: update QEMU 2.9.0 caps data Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-03-21 14:45:00 +03:00
<property name='kvm-no-smi-migration' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='monitor' type='boolean' value='false'/>
<property name='avx512er' type='boolean' value='false'/>
<property name='pmm-en' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='pcid' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='3dnow' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='erms' type='boolean' value='true' migratable='yes'/>
<property name='lahf-lm' type='boolean' value='true' migratable='yes'/>
<property name='lahf_lm' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='xstore' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-synic' type='boolean' value='false'/>
<property name='fxsr-opt' type='boolean' value='false'/>
<property name='fxsr_opt' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='rtm' type='boolean' value='true' migratable='yes'/>
<property name='lmce' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-time' type='boolean' value='false'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='perfctr-nb' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='perfctr_nb' type='boolean' value='false'/>
<property name='ffxsr' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='rdrand' type='boolean' value='true' migratable='yes'/>
<property name='rdseed' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='avx512-4vnniw' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='vme' type='boolean' value='true' migratable='yes'/>
<property name='vmx' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='dtes64' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='mtrr' type='boolean' value='true' migratable='yes'/>
<property name='rdtscp' type='boolean' value='true' migratable='yes'/>
<property name='pse36' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='tbm' type='boolean' value='false'/>
<property name='wdt' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='pause_filter' type='boolean' value='false'/>
qemu: Store more types in qemuMonitorCPUModelInfo While query-cpu-model-expansion returns only boolean features on s390, but x86_64 reports some integer and string properties which we are interested in. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:01:30 +03:00
<property name='model-id' type='string' value='Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='sha-ni' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='abm' type='boolean' value='true' migratable='yes'/>
qemu: Prepare for more types in qemuMonitorCPUModelInfo Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 17:46:47 +03:00
<property name='avx512pf' type='boolean' value='false'/>
<property name='xstore-en' type='boolean' value='false'/>
qemucapstest: Update test data for QEMU 2.9.0 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 18:10:22 +03:00
</hostCPU>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<hostCPU type='tcg' model='base' migratability='yes'>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='phys-bits' type='number' value='0'/>
<property name='core-id' type='number' value='-1'/>
<property name='xlevel' type='number' value='2147483658'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='cmov' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='ia64' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='aes' type='boolean' value='true' migratable='yes'/>
<property name='mmx' type='boolean' value='true' migratable='yes'/>
<property name='arat' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='rdpid' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='pause-filter' type='boolean' value='false'/>
<property name='xsavec' type='boolean' value='false'/>
<property name='osxsave' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='tsc-frequency' type='number' value='0'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xd' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-vendor-id' type='string' value=''/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='kvm-asyncpf' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='kvm_asyncpf' type='boolean' value='false'/>
<property name='perfctr_core' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='perfctr-core' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='mpx' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='avx512cd' type='boolean' value='false'/>
<property name='decodeassists' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='pbe' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='sse4_1' type='boolean' value='true' migratable='yes'/>
<property name='sse4.1' type='boolean' value='true' migratable='yes'/>
<property name='sse4-1' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='family' type='number' value='6'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='vmware-cpuid-freq' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='avx512f' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='xcrypt' type='boolean' value='false'/>
<property name='hv-runtime' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='msr' type='boolean' value='true' migratable='yes'/>
<property name='mce' type='boolean' value='true' migratable='yes'/>
<property name='mca' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='thread-id' type='number' value='-1'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='min-level' type='number' value='13'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xgetbv1' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='cid' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-relaxed' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='fxsr' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='ds' type='boolean' value='false'/>
<property name='hv-crash' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xsaveopt' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='xtpr' type='boolean' value='false'/>
<property name='avx512-vpopcntdq' type='boolean' value='false'/>
<property name='phe' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='avx512vl' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='extapic' type='boolean' value='false'/>
<property name='3dnowprefetch' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='cr8legacy' type='boolean' value='true' migratable='yes'/>
<property name='cpuid-0xb' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='xcrypt-en' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='kvm_pv_eoi' type='boolean' value='false'/>
<property name='apic-id' type='number' value='4294967295'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='pn' type='boolean' value='false'/>
<property name='dca' type='boolean' value='false'/>
<property name='vendor' type='string' value='AuthenticAMD'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='pku' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='smx' type='boolean' value='false'/>
<property name='cmp-legacy' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='cmp_legacy' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='avx512-4fmaps' type='boolean' value='false'/>
<property name='vmcb-clean' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='vmcb_clean' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='3dnowext' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hle' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='npt' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='memory' type='string' value='/machine/unattached/system[0]'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='clwb' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='lbrv' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='adx' type='boolean' value='true' migratable='yes'/>
<property name='ss' type='boolean' value='true' migratable='yes'/>
<property name='pni' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='svm_lock' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='svm-lock' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='smep' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='pfthreshold' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='smap' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='x2apic' type='boolean' value='false'/>
<property name='avx512vbmi' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-stimer' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='i64' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='flushbyasid' type='boolean' value='false'/>
<property name='f16c' type='boolean' value='false'/>
<property name='ace2-en' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='pat' type='boolean' value='true' migratable='yes'/>
<property name='pae' type='boolean' value='true' migratable='yes'/>
<property name='sse' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='phe-en' type='boolean' value='false'/>
<property name='kvm-nopiodelay' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='kvm_nopiodelay' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='tm' type='boolean' value='false'/>
<property name='kvmclock-stable-bit' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='hypervisor' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='socket-id' type='number' value='-1'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='pcommit' type='boolean' value='true' migratable='yes'/>
<property name='syscall' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='level' type='number' value='13'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='avx512dq' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='svm' type='boolean' value='true' migratable='yes'/>
<property name='full-cpuid-auto-level' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-reset' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='invtsc' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='sse3' type='boolean' value='true' migratable='yes'/>
<property name='sse2' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='est' type='boolean' value='false'/>
<property name='avx512ifma' type='boolean' value='false'/>
<property name='tm2' type='boolean' value='false'/>
<property name='kvm-pv-eoi' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='cx8' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='kvm-mmu' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='kvm_mmu' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='sse4_2' type='boolean' value='true' migratable='yes'/>
<property name='sse4.2' type='boolean' value='true' migratable='yes'/>
<property name='sse4-2' type='boolean' value='true' migratable='yes'/>
<property name='pge' type='boolean' value='true' migratable='yes'/>
<property name='fill-mtrr-mask' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='pdcm' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='nodeid_msr' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='model' type='number' value='6'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='movbe' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='nrip-save' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='nrip_save' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='sse4a' type='boolean' value='true' migratable='yes'/>
<property name='ssse3' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='kvm_pv_unhalt' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='invpcid' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='pdpe1gb' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='tsc-deadline' type='boolean' value='false'/>
<property name='fma' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='cx16' type='boolean' value='true' migratable='yes'/>
<property name='de' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='enforce' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='stepping' type='number' value='3'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='xsave' type='boolean' value='true' migratable='yes'/>
<property name='clflush' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='skinit' type='boolean' value='false'/>
<property name='tce' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='tsc' type='boolean' value='true' migratable='yes'/>
<property name='fpu' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='ds-cpl' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='ds_cpl' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='ibs' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='host-phys-bits' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='fma4' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='la57' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='osvw' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='check' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-spinlocks' type='number' value='-1'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='pmm' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='apic' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='pmu' type='boolean' value='false'/>
<property name='min-xlevel2' type='number' value='0'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='tsc-adjust' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='tsc_adjust' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='kvm-steal-time' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='kvm_steal_time' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='kvmclock' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='l3-cache' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='lwp' type='boolean' value='false'/>
<property name='xop' type='boolean' value='false'/>
<property name='avx' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='ospke' type='boolean' value='true' migratable='yes'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='ace2' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='acpi' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='avx512bw' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-vapic' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='fsgsbase' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='ht' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='nx' type='boolean' value='true' migratable='yes'/>
<property name='pclmulqdq' type='boolean' value='true' migratable='yes'/>
<property name='mmxext' type='boolean' value='true' migratable='yes'/>
<property name='popcnt' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='xsaves' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='lm' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='umip' type='boolean' value='false'/>
<property name='avx2' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='pse' type='boolean' value='true' migratable='yes'/>
<property name='sep' type='boolean' value='true' migratable='yes'/>
<property name='pclmuldq' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='nodeid-msr' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='kvm' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='misalignsse' type='boolean' value='false'/>
<property name='min-xlevel' type='number' value='2147483658'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='bmi2' type='boolean' value='true' migratable='yes'/>
<property name='bmi1' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='kvm-pv-unhalt' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='realized' type='boolean' value='false'/>
<property name='tsc_scale' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='tsc-scale' type='boolean' value='false'/>
<property name='topoext' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-vpindex' type='boolean' value='false'/>
<property name='xlevel2' type='number' value='0'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='clflushopt' type='boolean' value='true' migratable='yes'/>
tests: update QEMU 2.9.0 caps data Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-03-21 14:45:00 +03:00
<property name='kvm-no-smi-migration' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='monitor' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='avx512er' type='boolean' value='false'/>
<property name='pmm-en' type='boolean' value='false'/>
<property name='pcid' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='3dnow' type='boolean' value='true' migratable='yes'/>
<property name='erms' type='boolean' value='true' migratable='yes'/>
<property name='lahf-lm' type='boolean' value='true' migratable='yes'/>
<property name='lahf_lm' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='xstore' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-synic' type='boolean' value='false'/>
<property name='fxsr-opt' type='boolean' value='false'/>
<property name='fxsr_opt' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='rtm' type='boolean' value='false'/>
<property name='lmce' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='hv-time' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='perfctr-nb' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='perfctr_nb' type='boolean' value='false'/>
<property name='ffxsr' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='rdrand' type='boolean' value='false'/>
<property name='rdseed' type='boolean' value='false'/>
<property name='avx512-4vnniw' type='boolean' value='false'/>
<property name='vme' type='boolean' value='false'/>
<property name='vmx' type='boolean' value='false'/>
<property name='dtes64' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='mtrr' type='boolean' value='true' migratable='yes'/>
<property name='rdtscp' type='boolean' value='true' migratable='yes'/>
<property name='pse36' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='tbm' type='boolean' value='false'/>
<property name='wdt' type='boolean' value='false'/>
qemu: Use full CPU model expansion on x86 The static CPU model expansion is designed to return only canonical names of all CPU properties. To maintain backwards compatibility libvirt is stuck with different spelling of some of the features, but we need to use the full expansion to get the additional spellings. In addition to returning all spelling variants for all properties the full expansion will contain properties which are not guaranteed to be migration compatible. Thus, we need to combine both expansions. First we need to call the static expansion to limit the result to migratable properties. Then we can use the result of the static expansion as an input to the full expansion to get both canonical names and their aliases. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-23 15:53:51 +03:00
<property name='pause_filter' type='boolean' value='false'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='model-id' type='string' value='QEMU TCG CPU version 2.5+'/>
<property name='sha-ni' type='boolean' value='false'/>
qemu: Check migratable host CPU features If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-03-29 11:58:41 +03:00
<property name='abm' type='boolean' value='true' migratable='yes'/>
qemu: Probe "max" CPU model in TCG Querying "host" CPU model expansion only makes sense for KVM. QEMU 2.9.0 introduces a new "max" CPU model which can be used to ask QEMU what the best CPU it can provide to a TCG domain is. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-02-22 18:51:50 +03:00
<property name='avx512pf' type='boolean' value='false'/>
<property name='xstore-en' type='boolean' value='false'/>
</hostCPU>
qemucapstest: Update test data for QEMU 2.9.0 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 18:10:22 +03:00
<cpu type='kvm' name='max' usable='yes'/>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='kvm' name='host' usable='yes'/>
qemucapstest: Update test data for QEMU 2.9.0 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 18:10:22 +03:00
<cpu type='kvm' name='base' usable='yes'/>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='kvm' name='qemu64' usable='yes'/>
<cpu type='kvm' name='qemu32' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='kvm' name='phenom' usable='no'>
<blocker name='mmxext'/>
<blocker name='fxsr-opt'/>
<blocker name='3dnowext'/>
<blocker name='3dnow'/>
<blocker name='sse4a'/>
<blocker name='npt'/>
</cpu>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='kvm' name='pentium3' usable='yes'/>
<cpu type='kvm' name='pentium2' usable='yes'/>
<cpu type='kvm' name='pentium' usable='yes'/>
<cpu type='kvm' name='n270' usable='yes'/>
<cpu type='kvm' name='kvm64' usable='yes'/>
<cpu type='kvm' name='kvm32' usable='yes'/>
<cpu type='kvm' name='coreduo' usable='yes'/>
<cpu type='kvm' name='core2duo' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='kvm' name='athlon' usable='no'>
<blocker name='mmxext'/>
<blocker name='3dnowext'/>
<blocker name='3dnow'/>
</cpu>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='kvm' name='Westmere' usable='yes'/>
<cpu type='kvm' name='Skylake-Client' usable='yes'/>
<cpu type='kvm' name='SandyBridge' usable='yes'/>
<cpu type='kvm' name='Penryn' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='kvm' name='Opteron_G5' usable='no'>
<blocker name='sse4a'/>
<blocker name='misalignsse'/>
<blocker name='xop'/>
<blocker name='fma4'/>
<blocker name='tbm'/>
</cpu>
<cpu type='kvm' name='Opteron_G4' usable='no'>
<blocker name='sse4a'/>
<blocker name='misalignsse'/>
<blocker name='xop'/>
<blocker name='fma4'/>
</cpu>
<cpu type='kvm' name='Opteron_G3' usable='no'>
<blocker name='sse4a'/>
<blocker name='misalignsse'/>
</cpu>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='kvm' name='Opteron_G2' usable='yes'/>
<cpu type='kvm' name='Opteron_G1' usable='yes'/>
<cpu type='kvm' name='Nehalem' usable='yes'/>
<cpu type='kvm' name='IvyBridge' usable='yes'/>
<cpu type='kvm' name='Haswell' usable='yes'/>
<cpu type='kvm' name='Haswell-noTSX' usable='yes'/>
<cpu type='kvm' name='Conroe' usable='yes'/>
<cpu type='kvm' name='Broadwell' usable='yes'/>
<cpu type='kvm' name='Broadwell-noTSX' usable='yes'/>
<cpu type='kvm' name='486' usable='yes'/>
qemucapstest: Update test data for QEMU 2.9.0 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 18:10:22 +03:00
<cpu type='tcg' name='max' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='tcg' name='host' usable='no'>
<blocker name='kvm'/>
</cpu>
qemucapstest: Update test data for QEMU 2.9.0 Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-01-30 18:10:22 +03:00
<cpu type='tcg' name='base' usable='yes'/>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='tcg' name='qemu64' usable='yes'/>
<cpu type='tcg' name='qemu32' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='tcg' name='phenom' usable='no'>
<blocker name='fxsr-opt'/>
<blocker name='npt'/>
</cpu>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='tcg' name='pentium3' usable='yes'/>
<cpu type='tcg' name='pentium2' usable='yes'/>
<cpu type='tcg' name='pentium' usable='yes'/>
<cpu type='tcg' name='n270' usable='yes'/>
<cpu type='tcg' name='kvm64' usable='yes'/>
<cpu type='tcg' name='kvm32' usable='yes'/>
<cpu type='tcg' name='coreduo' usable='yes'/>
<cpu type='tcg' name='core2duo' usable='yes'/>
<cpu type='tcg' name='athlon' usable='yes'/>
<cpu type='tcg' name='Westmere' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='tcg' name='Skylake-Client' usable='no'>
<blocker name='fma'/>
<blocker name='pcid'/>
<blocker name='x2apic'/>
<blocker name='tsc-deadline'/>
<blocker name='avx'/>
<blocker name='f16c'/>
<blocker name='rdrand'/>
<blocker name='hle'/>
<blocker name='avx2'/>
<blocker name='invpcid'/>
<blocker name='rtm'/>
<blocker name='rdseed'/>
<blocker name='3dnowprefetch'/>
<blocker name='xsavec'/>
</cpu>
<cpu type='tcg' name='SandyBridge' usable='no'>
<blocker name='x2apic'/>
<blocker name='tsc-deadline'/>
<blocker name='avx'/>
</cpu>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='tcg' name='Penryn' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='tcg' name='Opteron_G5' usable='no'>
<blocker name='fma'/>
<blocker name='avx'/>
<blocker name='f16c'/>
<blocker name='misalignsse'/>
<blocker name='3dnowprefetch'/>
<blocker name='xop'/>
<blocker name='fma4'/>
<blocker name='tbm'/>
</cpu>
<cpu type='tcg' name='Opteron_G4' usable='no'>
<blocker name='avx'/>
<blocker name='misalignsse'/>
<blocker name='3dnowprefetch'/>
<blocker name='xop'/>
<blocker name='fma4'/>
</cpu>
<cpu type='tcg' name='Opteron_G3' usable='no'>
<blocker name='misalignsse'/>
</cpu>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='tcg' name='Opteron_G2' usable='yes'/>
<cpu type='tcg' name='Opteron_G1' usable='yes'/>
<cpu type='tcg' name='Nehalem' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='tcg' name='IvyBridge' usable='no'>
<blocker name='x2apic'/>
<blocker name='tsc-deadline'/>
<blocker name='avx'/>
<blocker name='f16c'/>
<blocker name='rdrand'/>
</cpu>
<cpu type='tcg' name='Haswell' usable='no'>
<blocker name='fma'/>
<blocker name='pcid'/>
<blocker name='x2apic'/>
<blocker name='tsc-deadline'/>
<blocker name='avx'/>
<blocker name='f16c'/>
<blocker name='rdrand'/>
<blocker name='hle'/>
<blocker name='avx2'/>
<blocker name='invpcid'/>
<blocker name='rtm'/>
</cpu>
<cpu type='tcg' name='Haswell-noTSX' usable='no'>
<blocker name='fma'/>
<blocker name='pcid'/>
<blocker name='x2apic'/>
<blocker name='tsc-deadline'/>
<blocker name='avx'/>
<blocker name='f16c'/>
<blocker name='rdrand'/>
<blocker name='avx2'/>
<blocker name='invpcid'/>
</cpu>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='tcg' name='Conroe' usable='yes'/>
qemu: Parse unavailable features for CPU models query-cpu-definitions QMP command returns a list of unavailable features which prevent CPU models from being usable on the current host. So far we only checked whether the list was empty to mark CPU models as (un)usable. This patch parses all unavailable features for each CPU model and stores them in virDomainCapsCPUModel as a list of usability blockers. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-09-20 11:45:49 +03:00
<cpu type='tcg' name='Broadwell' usable='no'>
<blocker name='fma'/>
<blocker name='pcid'/>
<blocker name='x2apic'/>
<blocker name='tsc-deadline'/>
<blocker name='avx'/>
<blocker name='f16c'/>
<blocker name='rdrand'/>
<blocker name='hle'/>
<blocker name='avx2'/>
<blocker name='invpcid'/>
<blocker name='rtm'/>
<blocker name='rdseed'/>
<blocker name='3dnowprefetch'/>
</cpu>
<cpu type='tcg' name='Broadwell-noTSX' usable='no'>
<blocker name='fma'/>
<blocker name='pcid'/>
<blocker name='x2apic'/>
<blocker name='tsc-deadline'/>
<blocker name='avx'/>
<blocker name='f16c'/>
<blocker name='rdrand'/>
<blocker name='avx2'/>
<blocker name='invpcid'/>
<blocker name='rdseed'/>
<blocker name='3dnowprefetch'/>
</cpu>
tests: add QEMU 2.9.0 caps data QEMU 2.9.0 is not released yet but it's close to its release and we need this data to implement new features that will be in that release. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-02-20 01:47:21 +03:00
<cpu type='tcg' name='486' usable='yes'/>
<machine name='pc-i440fx-2.9' alias='pc' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-0.12' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.4' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-1.3' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-q35-2.7' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-q35-2.6' hotplugCpus='yes' maxCpus='255'/>
<machine name='xenpv' maxCpus='1'/>
<machine name='pc-i440fx-1.7' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.8' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-1.6' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.7' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-0.11' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.3' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-0.10' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-1.2' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.2' hotplugCpus='yes' maxCpus='255'/>
<machine name='isapc' hotplugCpus='yes' maxCpus='1'/>
<machine name='pc-q35-2.5' hotplugCpus='yes' maxCpus='255'/>
<machine name='xenfv' hotplugCpus='yes' maxCpus='128'/>
<machine name='pc-0.15' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-0.14' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-1.5' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.6' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-1.4' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.5' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-q35-2.9' alias='q35' hotplugCpus='yes' maxCpus='288'/>
<machine name='pc-1.1' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.1' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-q35-2.8' hotplugCpus='yes' maxCpus='288'/>
<machine name='pc-1.0' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-i440fx-2.0' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-q35-2.4' hotplugCpus='yes' maxCpus='255'/>
<machine name='pc-0.13' hotplugCpus='yes' maxCpus='255'/>
</qemuCaps>
Copy Permalink