shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-25 01:34:11 +03:00
Code Releases Activity
ad5c4be09f
libvirt/tests/domaincapsdata/qemu_4.2.0-q35.x86_64.xml

229 lines
8.0 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'>
<value>/usr/share/AAVMF/AAVMF_CODE.fd</value>
<value>/usr/share/AAVMF/AAVMF32_CODE.fd</value>
<value>/usr/share/OVMF/OVMF_CODE.fd</value>
<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>
<feature policy='require' name='ss'/>
<feature policy='require' name='vmx'/>
<feature policy='require' name='hypervisor'/>
<feature policy='require' name='tsc_adjust'/>
<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'/>
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: 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>
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'/>
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'/>
</features>
</domainCapabilities>
Copy Permalink