shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-01-06 17:17:56 +03:00
Code Releases Activity
a91b22ffc6
libvirt/tests/domaincapsdata/qemu_4.2.0-q35.x86_64.xml

330 lines
13 KiB
XML
Raw Normal View History

tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<domainCapabilities>
<path>/usr/bin/qemu-system-x86_64</path>
<domain>kvm</domain>
<machine>pc-q35-4.2</machine>
<arch>x86_64</arch>
<vcpu max='288'/>
<iothreads supported='yes'/>
<os supported='yes'>
<enum name='firmware'>
<value>bios</value>
<value>efi</value>
</enum>
<loader supported='yes'>
domaincapstest: Use obviously fake firmware name in capabilities The domain capabilities data feature a firmware section which is filled by few entries. The entries used until now looked real and it was suspicious that a x86_64 host was listing aarch64 firmware images which should not happen. Fill it by an obviously fake path as it's not actually interpreted in a meaningful way. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-04-03 14:20:47 +03:00
<value>/obviously/fake/firmware1.fd</value>
<value>/obviously/fake/firmware2.fd</value>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<enum name='type'>
<value>rom</value>
<value>pflash</value>
</enum>
<enum name='readonly'>
<value>yes</value>
<value>no</value>
</enum>
<enum name='secure'>
<value>yes</value>
<value>no</value>
</enum>
</loader>
</os>
<cpu>
qemu: Advertise migratable attribute for CPU in domcaps Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-03 01:28:10 +03:00
<mode name='host-passthrough' supported='yes'>
<enum name='hostPassthroughMigratable'>
<value>on</value>
<value>off</value>
</enum>
</mode>
qemu: wire up support for maximum CPU model The "max" model can be treated the same way as "host" model in general. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-05 21:35:10 +03:00
<mode name='maximum' supported='yes'>
<enum name='maximumMigratable'>
<value>on</value>
<value>off</value>
</enum>
</mode>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<mode name='host-model' supported='yes'>
<model fallback='forbid'>Skylake-Client-IBRS</model>
<vendor>Intel</vendor>
qemu: Report physical address size in domain capabilities We already report the hosts physical address size in host capabilities, but computing a baseline CPU definition is done from domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-06-09 18:17:36 +03:00
<maxphysaddr mode='passthrough' limit='64'/>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<feature policy='require' name='vmx'/>
<feature policy='require' name='hypervisor'/>
cpu_map: Sort cpu features Some feature words were not sorted correctly. Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2024-02-02 00:03:49 +03:00
<feature policy='require' name='ss'/>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<feature policy='require' name='tsc_adjust'/>
cpu_map: Drop 'mpx' from x86 cpu models The mpx feature was removed from the corresponding qemu cpu models. With mpx in the libvirt cpu models, libvirt believes the feature to be implicitly enabled when creating qemu VMs, while in fact it is disabled. This became an issue when commit 94eacd5a5f introduced new vmx-* features, of which some are dependent on mpx (see "feature_dependencies" table in qemu target/i386/cpu.c), e.g. vmx-exit-clear-bndcfgs and vmx-entry-load-bndcfgs. These features cannot be enabled by qemu without also mpx being enabled, leading to the error message error: Failed to create domain from testdomain.xml error: operation failed: guest CPU doesn't match specification: missing features: mpx,vmx-exit-clear-bndcfgs, vmx-entry-load-bndcfgs when trying to create a VM with a "host-model" cpu on a host that does support mpx and the mentioned vmx-* features: <domain> ... <cpu mode='host-model' check='full' /> ... </domain> Resolve the issue by removing mpx from libvirt's cpu models as well. Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-02-09 13:52:56 +03:00
<feature policy='require' name='mpx'/>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<feature policy='require' name='clflushopt'/>
<feature policy='require' name='umip'/>
<feature policy='require' name='md-clear'/>
<feature policy='require' name='stibp'/>
<feature policy='require' name='arch-capabilities'/>
<feature policy='require' name='ssbd'/>
<feature policy='require' name='xsaves'/>
<feature policy='require' name='pdpe1gb'/>
<feature policy='require' name='invtsc'/>
<feature policy='require' name='skip-l1dfl-vmentry'/>
cpu_map: Add pschange-mc-no bit in IA32_ARCH_CAPABILITIES MSR Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2020-05-18 21:55:42 +03:00
<feature policy='require' name='pschange-mc-no'/>
cpu_map: Add missing vmx features from MSR 0x480 Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:33:38 +03:00
<feature policy='require' name='vmx-ins-outs'/>
<feature policy='require' name='vmx-true-ctls'/>
cpu_map: Add missing vmx features from MSR 0x485 Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:35:39 +03:00
<feature policy='require' name='vmx-store-lma'/>
<feature policy='require' name='vmx-activity-hlt'/>
<feature policy='require' name='vmx-vmwrite-vmexit-fields'/>
cpu_map: Add missing vmx features from MSR 0x48B Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:36:30 +03:00
<feature policy='require' name='vmx-apicv-xapic'/>
<feature policy='require' name='vmx-ept'/>
<feature policy='require' name='vmx-desc-exit'/>
<feature policy='require' name='vmx-rdtscp-exit'/>
<feature policy='require' name='vmx-apicv-x2apic'/>
<feature policy='require' name='vmx-vpid'/>
<feature policy='require' name='vmx-wbinvd-exit'/>
<feature policy='require' name='vmx-unrestricted-guest'/>
<feature policy='require' name='vmx-rdrand-exit'/>
<feature policy='require' name='vmx-invpcid-exit'/>
<feature policy='require' name='vmx-vmfunc'/>
<feature policy='require' name='vmx-shadow-vmcs'/>
<feature policy='require' name='vmx-rdseed-exit'/>
<feature policy='require' name='vmx-pml'/>
<feature policy='require' name='vmx-xsaves'/>
cpu_map: Add missing vmx features from MSR 0x48C Differences from qemu: * "vmx-ept-uc" (bit 8) and "vmx-ept-wb" (bit 14) are not added to qemu's list of named features yet, but used in several qemu cpu models never the less. Add to libvirt regardless. * "vmx-invvpid-single-context" (bit 41) is erroneously called "vmx-invept-single-context" in qemu. This is the name of the feature associated with bit 25 in both libvirt and qemu. * "vmx-invvpid-single-context-noglobals" (bit 43) is erroneously called "vmx-invept-single-context-noglobals". Use the correct name. Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:37:19 +03:00
<feature policy='require' name='vmx-ept-execonly'/>
<feature policy='require' name='vmx-page-walk-4'/>
<feature policy='require' name='vmx-ept-2mb'/>
<feature policy='require' name='vmx-ept-1gb'/>
<feature policy='require' name='vmx-invept'/>
<feature policy='require' name='vmx-eptad'/>
<feature policy='require' name='vmx-invept-single-context'/>
<feature policy='require' name='vmx-invept-all-context'/>
cpu_map: Sort cpu features Some feature words were not sorted correctly. Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2024-02-02 00:03:49 +03:00
<feature policy='require' name='vmx-invvpid'/>
<feature policy='require' name='vmx-invvpid-single-addr'/>
<feature policy='require' name='vmx-invvpid-all-context'/>
cpu_map: Add missing vmx features from MSR 0x48D Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:38:10 +03:00
<feature policy='require' name='vmx-intr-exit'/>
<feature policy='require' name='vmx-nmi-exit'/>
<feature policy='require' name='vmx-vnmi'/>
<feature policy='require' name='vmx-preemption-timer'/>
cpu_map: Add missing vmx features from MSR 0x48E Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:39:17 +03:00
<feature policy='require' name='vmx-vintr-pending'/>
<feature policy='require' name='vmx-tsc-offset'/>
<feature policy='require' name='vmx-hlt-exit'/>
<feature policy='require' name='vmx-invlpg-exit'/>
<feature policy='require' name='vmx-mwait-exit'/>
<feature policy='require' name='vmx-rdpmc-exit'/>
<feature policy='require' name='vmx-rdtsc-exit'/>
<feature policy='require' name='vmx-cr3-load-noexit'/>
<feature policy='require' name='vmx-cr3-store-noexit'/>
<feature policy='require' name='vmx-cr8-load-exit'/>
<feature policy='require' name='vmx-cr8-store-exit'/>
<feature policy='require' name='vmx-flexpriority'/>
<feature policy='require' name='vmx-vnmi-pending'/>
<feature policy='require' name='vmx-movdr-exit'/>
<feature policy='require' name='vmx-io-exit'/>
<feature policy='require' name='vmx-io-bitmap'/>
<feature policy='require' name='vmx-mtf'/>
<feature policy='require' name='vmx-msr-bitmap'/>
<feature policy='require' name='vmx-monitor-exit'/>
<feature policy='require' name='vmx-pause-exit'/>
<feature policy='require' name='vmx-secondary-ctls'/>
cpu_map: Add missing vmx features from MSR 0x48F Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:39:59 +03:00
<feature policy='require' name='vmx-exit-nosave-debugctl'/>
<feature policy='require' name='vmx-exit-ack-intr'/>
<feature policy='require' name='vmx-exit-save-pat'/>
<feature policy='require' name='vmx-exit-load-pat'/>
<feature policy='require' name='vmx-exit-save-efer'/>
<feature policy='require' name='vmx-exit-load-efer'/>
<feature policy='require' name='vmx-exit-save-preemption-timer'/>
cpu_map: Add missing vmx features from MSR 0x490 Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:41:35 +03:00
<feature policy='require' name='vmx-entry-noload-debugctl'/>
<feature policy='require' name='vmx-entry-ia32e-mode'/>
<feature policy='require' name='vmx-entry-load-pat'/>
<feature policy='require' name='vmx-entry-load-efer'/>
cpu_map: Add missing vmx features from MSR 0x491 Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2023-11-09 16:42:10 +03:00
<feature policy='require' name='vmx-eptp-switching'/>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
</mode>
<mode name='custom' supported='yes'>
domain_capabilities: Add vendor attribute for CPU models Even though several CPU models from various vendors are reported as usable on a given host, user may still want to use only those that match the host vendor. Currently the only place where users can check the vendor of each CPU model is our CPU map, which is considered internal and users should not really be using it directly. So to allow for such filtering we now advertise the vendor of each CPU model in domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-09-30 12:46:29 +03:00
<model usable='yes' vendor='unknown'>qemu64</model>
<model usable='yes' vendor='unknown'>qemu32</model>
cpu_x86: Implement virCPUGetVendorForModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-09-29 22:40:40 +03:00
<model usable='no' vendor='AMD'>phenom</model>
domain_capabilities: Add vendor attribute for CPU models Even though several CPU models from various vendors are reported as usable on a given host, user may still want to use only those that match the host vendor. Currently the only place where users can check the vendor of each CPU model is our CPU map, which is considered internal and users should not really be using it directly. So to allow for such filtering we now advertise the vendor of each CPU model in domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-09-30 12:46:29 +03:00
<model usable='yes' vendor='unknown'>pentium3</model>
<model usable='yes' vendor='unknown'>pentium2</model>
<model usable='yes' vendor='unknown'>pentium</model>
cpu_x86: Implement virCPUGetVendorForModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-09-29 22:40:40 +03:00
<model usable='yes' vendor='Intel'>n270</model>
domain_capabilities: Add vendor attribute for CPU models Even though several CPU models from various vendors are reported as usable on a given host, user may still want to use only those that match the host vendor. Currently the only place where users can check the vendor of each CPU model is our CPU map, which is considered internal and users should not really be using it directly. So to allow for such filtering we now advertise the vendor of each CPU model in domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-09-30 12:46:29 +03:00
<model usable='yes' vendor='unknown'>kvm64</model>
<model usable='yes' vendor='unknown'>kvm32</model>
cpu_x86: Implement virCPUGetVendorForModel Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-09-29 22:40:40 +03:00
<model usable='yes' vendor='Intel'>coreduo</model>
<model usable='yes' vendor='Intel'>core2duo</model>
<model usable='no' vendor='AMD'>athlon</model>
<model usable='yes' vendor='Intel'>Westmere-IBRS</model>
<model usable='yes' vendor='Intel'>Westmere</model>
<model usable='no' vendor='Intel'>Snowridge</model>
<model usable='no' vendor='Intel'>Skylake-Server-noTSX-IBRS</model>
<model usable='no' vendor='Intel'>Skylake-Server-IBRS</model>
<model usable='no' vendor='Intel'>Skylake-Server</model>
<model usable='yes' vendor='Intel'>Skylake-Client-noTSX-IBRS</model>
<model usable='yes' vendor='Intel'>Skylake-Client-IBRS</model>
<model usable='yes' vendor='Intel'>Skylake-Client</model>
<model usable='yes' vendor='Intel'>SandyBridge-IBRS</model>
<model usable='yes' vendor='Intel'>SandyBridge</model>
<model usable='yes' vendor='Intel'>Penryn</model>
<model usable='no' vendor='AMD'>Opteron_G5</model>
<model usable='no' vendor='AMD'>Opteron_G4</model>
<model usable='no' vendor='AMD'>Opteron_G3</model>
<model usable='yes' vendor='AMD'>Opteron_G2</model>
<model usable='yes' vendor='AMD'>Opteron_G1</model>
<model usable='yes' vendor='Intel'>Nehalem-IBRS</model>
<model usable='yes' vendor='Intel'>Nehalem</model>
<model usable='yes' vendor='Intel'>IvyBridge-IBRS</model>
<model usable='yes' vendor='Intel'>IvyBridge</model>
<model usable='no' vendor='Intel'>Icelake-Server-noTSX</model>
<model usable='no' vendor='Intel'>Icelake-Server</model>
<model usable='no' vendor='Intel'>Icelake-Client-noTSX</model>
<model usable='no' vendor='Intel'>Icelake-Client</model>
<model usable='yes' vendor='Intel'>Haswell-noTSX-IBRS</model>
<model usable='yes' vendor='Intel'>Haswell-noTSX</model>
<model usable='yes' vendor='Intel'>Haswell-IBRS</model>
<model usable='yes' vendor='Intel'>Haswell</model>
<model usable='no' vendor='AMD'>EPYC-IBPB</model>
<model usable='no' vendor='AMD'>EPYC</model>
<model usable='no' vendor='Hygon'>Dhyana</model>
<model usable='yes' vendor='Intel'>Conroe</model>
<model usable='no' vendor='Intel'>Cascadelake-Server-noTSX</model>
<model usable='no' vendor='Intel'>Cascadelake-Server</model>
<model usable='yes' vendor='Intel'>Broadwell-noTSX-IBRS</model>
<model usable='yes' vendor='Intel'>Broadwell-noTSX</model>
<model usable='yes' vendor='Intel'>Broadwell-IBRS</model>
<model usable='yes' vendor='Intel'>Broadwell</model>
domain_capabilities: Add vendor attribute for CPU models Even though several CPU models from various vendors are reported as usable on a given host, user may still want to use only those that match the host vendor. Currently the only place where users can check the vendor of each CPU model is our CPU map, which is considered internal and users should not really be using it directly. So to allow for such filtering we now advertise the vendor of each CPU model in domain capabilities. Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-09-30 12:46:29 +03:00
<model usable='yes' vendor='unknown'>486</model>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
</mode>
</cpu>
qemu: capabilities: fill in domcaps <memoryBacking> Signed-off-by: Kristina Hanicova <khanicov@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-07-15 15:18:05 +03:00
<memoryBacking supported='yes'>
<enum name='sourceType'>
<value>file</value>
<value>anonymous</value>
<value>memfd</value>
</enum>
</memoryBacking>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<devices>
<disk supported='yes'>
<enum name='diskDevice'>
<value>disk</value>
<value>cdrom</value>
<value>floppy</value>
<value>lun</value>
</enum>
<enum name='bus'>
<value>fdc</value>
<value>scsi</value>
<value>virtio</value>
<value>usb</value>
<value>sata</value>
</enum>
<enum name='model'>
<value>virtio</value>
<value>virtio-transitional</value>
<value>virtio-non-transitional</value>
</enum>
</disk>
<graphics supported='yes'>
<enum name='type'>
<value>sdl</value>
<value>vnc</value>
<value>spice</value>
domcaps: Report egl-headless graphics type QEMU supports egl-headless if QEMU_CAPS_EGL_HEADLESS capability is present. There are some additional requirements but those are checked for in qemuValidateDomainDeviceDefGraphics() and depend on domain configuration and thus are not representable in domain capabilities. Let's stick with plain qemuCaps check then. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2020-11-17 13:00:26 +03:00
<value>egl-headless</value>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
</enum>
</graphics>
<video supported='yes'>
<enum name='modelType'>
<value>vga</value>
<value>cirrus</value>
<value>vmvga</value>
<value>qxl</value>
<value>virtio</value>
qemu: set domain capability for video type "none" In a follow-up commit, we will use the domain capabilities to validate video device configurations, which means that we also need to make sure that the domain capabilities include the "none" video device. Reviewed-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
2019-10-18 18:30:13 +03:00
<value>none</value>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<value>bochs</value>
qemu: set domain capability for ramfb device commit 9bfcf0f62d9cf16db526a948242a7409ae883209 added the QEMU_CAPS_DEVICE_RAMFB capability but did not set the domain capability. This patch sets the domain capability for the ramfb device and updates the tests. Reviewed-by: Cole Robinson <crobinso@redhat.com> Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
2019-10-18 18:30:12 +03:00
<value>ramfb</value>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
</enum>
</video>
<hostdev supported='yes'>
<enum name='mode'>
<value>subsystem</value>
</enum>
<enum name='startupPolicy'>
<value>default</value>
<value>mandatory</value>
<value>requisite</value>
<value>optional</value>
</enum>
<enum name='subsysType'>
<value>usb</value>
<value>pci</value>
<value>scsi</value>
</enum>
<enum name='capsType'/>
<enum name='pciBackend'>
<value>default</value>
<value>vfio</value>
</enum>
</hostdev>
<rng supported='yes'>
<enum name='model'>
<value>virtio</value>
<value>virtio-transitional</value>
<value>virtio-non-transitional</value>
</enum>
<enum name='backendModel'>
<value>random</value>
<value>egd</value>
qemu: Implement builtin rng backend Since v4.2-rc0, QEMU introduced a builtin rng backend that uses getrandom() syscall to generate random. Add it to libvirt with the backend model 'builtin'. https://bugzilla.redhat.com/show_bug.cgi?id=1785091 Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-01-09 11:00:08 +03:00
<value>builtin</value>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
</enum>
</rng>
qemu: capabilities: fill in domcaps <filesystem> Signed-off-by: Kristina Hanicova <khanicov@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-05-18 15:50:51 +03:00
<filesystem supported='yes'>
<enum name='driverType'>
<value>path</value>
<value>handle</value>
<value>virtiofs</value>
</enum>
</filesystem>
qemu: fill in domain capabilities for TPMs This reports what TPM features QEMU supports, provided that swtpm is installed in the host. Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-23 20:18:36 +03:00
<tpm supported='yes'>
<enum name='model'>
<value>tpm-tis</value>
<value>tpm-crb</value>
</enum>
<enum name='backendModel'>
<value>passthrough</value>
qemu: mock swtpm initialization in tests The domain capabilities won't report TPM support unless SWTPM can be initialized. To avoid relying on the swtpm install in the host, mock the entire initialization method, since all it needs todo is return a non-error value. Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-23 20:39:16 +03:00
<value>emulator</value>
qemu: add external backend for tpm Introduce a new backend type 'external' for connecting to a swtpm daemon not managed by libvirtd. Mostly in one commit, thanks to -Wswitch and the way we generate capabilities. https://bugzilla.redhat.com/show_bug.cgi?id=2063723 Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-10-17 16:20:24 +03:00
<value>external</value>
qemu: fill in domain capabilities for TPMs This reports what TPM features QEMU supports, provided that swtpm is installed in the host. Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-23 20:18:36 +03:00
</enum>
testutilsqemu: Fake TPM versions Because of v8.5.0-rc1~25 we are already faking TPM support for domaincaps. Might as well fake supported TPM versions. The swtpm binary supports both TPM versions since its first release, but pretend it isn't the case. For QEMU-5.2 and older pretend only TPM-1.2 is available, QEMU-6.* has both TPM-1.2 and TPM-2.0 and QEMU-7.0 and newer has only TPM-2.0 available. This way, domaincaps are more dispersed. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
2022-07-20 10:51:55 +03:00
<enum name='backendVersion'>
<value>1.2</value>
</enum>
qemu: fill in domain capabilities for TPMs This reports what TPM features QEMU supports, provided that swtpm is installed in the host. Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-11-23 20:18:36 +03:00
</tpm>
conf: Add USB redirect devices to domain capabilities As qemu becomes more modularized, it is important for libvirt to advertise availability of the modularized functionality through capabilities. This change adds USB redirect devices to domain capabilities, allowing clients such as virt-install to avoid using redirdev devices when not supported by the target qemu. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-08-31 00:29:14 +03:00
<redirdev supported='yes'>
<enum name='bus'>
<value>usb</value>
</enum>
</redirdev>
conf: Add channel devices to domain capabilities As qemu becomes more modularized, it is important for libvirt to advertise availability of the modularized functionality through capabilities. This change adds channel devices to domain capabilities, allowing clients such as virt-install to avoid using spicevmc channel devices when not supported by the target qemu. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-09-03 01:22:31 +03:00
<channel supported='yes'>
<enum name='type'>
<value>pty</value>
<value>unix</value>
<value>spicevmc</value>
</enum>
</channel>
capabilities: introduce crypto device Changes in this commit: - docs: formatdomaincaps.rst - conf: crypto related domain caps - qemu: crypto related - tests: crypto related test Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-17 04:46:51 +03:00
<crypto supported='yes'>
<enum name='model'>
<value>virtio</value>
</enum>
<enum name='type'>
<value>qemu</value>
</enum>
<enum name='backendModel'>
<value>builtin</value>
</enum>
</crypto>
qemu_capabilities: Fill supported net backend types Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-06-27 11:31:45 +03:00
<interface supported='yes'>
<enum name='backendType'>
<value>default</value>
</enum>
</interface>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
</devices>
<features>
<gic supported='no'/>
<vmcoreinfo supported='yes'/>
<genid supported='yes'/>
qemu: enable blockdev support Now that all pieces are in place (hopefully) let's enable -blockdev. We base the capability on presence of the fix for 'auto-read-only' on files so that blockdev works properly, mandate that qemu supports explicit SCSI id strings to avoid ABI regression and that the fix for 'savevm' is present so that internal snapshots work. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-07 13:45:19 +03:00
<backingStoreInput supported='yes'/>
qemu: Add support for VIR_DOMAIN_CAPS_FEATURE_BACKUP Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-12-03 19:38:13 +03:00
<backup supported='no'/>
conf: domcaps: Add 'async-teardown' domain capability Add async-teardown to the features list in domain capabilities allowing high level management to introspect the availability of the asynchronous teardown feature. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-07-17 18:12:08 +03:00
<async-teardown supported='no'/>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
<sev supported='no'/>
conf: expose SGX feature in domain capabilities Extend hypervisor capabilities to include sgx feature. When available, the hypervisor supports launching an VM with SGX on Intel platfrom. The SGX feature tag privides additional details like section size and sgx1 or sgx2. Signed-off-by: Haibin Huang <haibin.huang@intel.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-11 04:21:22 +03:00
<sgx supported='no'/>
qemu: Fill launchSecurity in domaincaps The inspiration for these rules comes from qemuValidateDomainDef(). Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2024-06-25 11:45:43 +03:00
<launchSecurity supported='no'/>
tests/domaincaps: Make test matrix programmatic For each QEMU version there are usually several different, architecture-dependedn scenarios that we're interested in testing; however, since the test matrix has to be explicitly created by calling DO_TEST_QEMU() multiple times with different arguments, we end up with spotty coverage. Fix this by implementing the arch-specific rules in code, which result in the full coverage for a (version, arch) combo being automatically achieved with a single call to DO_TEST_QEMU(). Unsurprisingly, this change results in a bunch of extra output files being created. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2019-10-22 18:16:26 +03:00
</features>
</domainCapabilities>
Copy Permalink