External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 21:55:25 +00:00
Code Issues Packages Projects Releases Wiki Activity
50c6d727b6
libvirt/tests/domaincapsdata/qemu_5.2.0.s390x.xml

289 lines
10 KiB
XML
Raw Normal View History

tests: add capabilities for QEMU 5.2.0 on s390x Let us introduce the xml and reply files for QEMU 5.2.0 on s390x. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-15 10:46:25 +00:00
<domainCapabilities>
<path>/usr/bin/qemu-system-s390x</path>
<domain>kvm</domain>
<machine>s390-ccw-virtio-5.2</machine>
<arch>s390x</arch>
<vcpu max='248'/>
<iothreads supported='yes'/>
<os supported='yes'>
<enum name='firmware'/>
<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 11:20:47 +00:00
<value>/obviously/fake/firmware1.fd</value>
<value>/obviously/fake/firmware2.fd</value>
tests: add capabilities for QEMU 5.2.0 on s390x Let us introduce the xml and reply files for QEMU 5.2.0 on s390x. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-15 10:46:25 +00: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>no</value>
</enum>
</loader>
</os>
<cpu>
<mode name='host-passthrough' supported='yes'>
<enum name='hostPassthroughMigratable'>
<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 18:35:10 +00:00
<mode name='maximum' supported='yes'>
<enum name='maximumMigratable'>
<value>on</value>
<value>off</value>
</enum>
</mode>
tests: add capabilities for QEMU 5.2.0 on s390x Let us introduce the xml and reply files for QEMU 5.2.0 on s390x. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-15 10:46:25 +00:00
<mode name='host-model' supported='yes'>
<model fallback='forbid'>gen15a-base</model>
<feature policy='require' name='aen'/>
<feature policy='require' name='cmmnt'/>
<feature policy='require' name='vxpdeh'/>
<feature policy='require' name='aefsi'/>
<feature policy='require' name='csske'/>
<feature policy='require' name='mepoch'/>
<feature policy='require' name='msa9'/>
<feature policy='require' name='msa8'/>
<feature policy='require' name='msa7'/>
<feature policy='require' name='msa6'/>
<feature policy='require' name='msa5'/>
<feature policy='require' name='msa4'/>
<feature policy='require' name='msa3'/>
<feature policy='require' name='msa2'/>
<feature policy='require' name='msa1'/>
<feature policy='require' name='sthyi'/>
<feature policy='require' name='edat'/>
<feature policy='require' name='ri'/>
<feature policy='require' name='deflate'/>
<feature policy='require' name='edat2'/>
<feature policy='require' name='etoken'/>
<feature policy='require' name='vx'/>
<feature policy='require' name='ipter'/>
<feature policy='require' name='mepochptff'/>
<feature policy='require' name='ap'/>
<feature policy='require' name='vxeh'/>
<feature policy='require' name='vxpd'/>
<feature policy='require' name='esop'/>
<feature policy='require' name='msa9_pckmo'/>
<feature policy='require' name='vxeh2'/>
<feature policy='require' name='esort'/>
<feature policy='require' name='apqi'/>
<feature policy='require' name='apft'/>
<feature policy='require' name='els'/>
<feature policy='require' name='iep'/>
<feature policy='require' name='apqci'/>
<feature policy='require' name='cte'/>
<feature policy='require' name='ais'/>
<feature policy='require' name='bpb'/>
<feature policy='require' name='gs'/>
<feature policy='require' name='ppa15'/>
<feature policy='require' name='zpci'/>
<feature policy='require' name='sea_esop2'/>
<feature policy='require' name='te'/>
<feature policy='require' name='cmm'/>
</mode>
<mode name='custom' supported='yes'>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>gen15a</model>
<model usable='yes' vendor='IBM'>gen15a-base</model>
<model usable='yes' vendor='IBM'>gen15b</model>
<model usable='yes' vendor='IBM'>gen15b-base</model>
<model usable='yes' vendor='unknown'>max</model>
<model usable='yes' vendor='unknown'>qemu</model>
<model usable='yes' vendor='IBM'>z10BC</model>
<model usable='yes' vendor='IBM'>z10BC-base</model>
<model usable='yes' vendor='IBM'>z10BC.2</model>
<model usable='yes' vendor='IBM'>z10BC.2-base</model>
<model usable='yes' vendor='IBM'>z10EC</model>
<model usable='yes' vendor='IBM'>z10EC-base</model>
<model usable='yes' vendor='IBM'>z10EC.2</model>
<model usable='yes' vendor='IBM'>z10EC.2-base</model>
<model usable='yes' vendor='IBM'>z10EC.3</model>
<model usable='yes' vendor='IBM'>z10EC.3-base</model>
<model usable='yes' vendor='IBM'>z114</model>
<model usable='yes' vendor='IBM'>z114-base</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z13</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z13-base</model>
<model usable='yes' vendor='IBM'>z13.2</model>
<model usable='yes' vendor='IBM'>z13.2-base</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z13s</model>
<model usable='yes' vendor='IBM'>z13s-base</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z14</model>
<model usable='yes' vendor='IBM'>z14-base</model>
<model usable='yes' vendor='IBM'>z14.2</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z14.2-base</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z14ZR1</model>
<model usable='yes' vendor='IBM'>z14ZR1-base</model>
<model usable='yes' vendor='IBM'>z196</model>
<model usable='yes' vendor='IBM'>z196-base</model>
<model usable='yes' vendor='IBM'>z196.2</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z196.2-base</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z800</model>
<model usable='yes' vendor='IBM'>z800-base</model>
<model usable='yes' vendor='IBM'>z890</model>
<model usable='yes' vendor='IBM'>z890-base</model>
<model usable='yes' vendor='IBM'>z890.2</model>
<model usable='yes' vendor='IBM'>z890.2-base</model>
<model usable='yes' vendor='IBM'>z890.3</model>
<model usable='yes' vendor='IBM'>z890.3-base</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z900</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z900-base</model>
<model usable='yes' vendor='IBM'>z900.2</model>
<model usable='yes' vendor='IBM'>z900.2-base</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z900.3</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z900.3-base</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z990</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z990-base</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z990.2</model>
<model usable='yes' vendor='IBM'>z990.2-base</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z990.3</model>
<model usable='yes' vendor='IBM'>z990.3-base</model>
<model usable='yes' vendor='IBM'>z990.4</model>
<model usable='yes' vendor='IBM'>z990.4-base</model>
<model usable='yes' vendor='IBM'>z990.5</model>
<model usable='yes' vendor='IBM'>z990.5-base</model>
<model usable='yes' vendor='IBM'>z9BC</model>
<model usable='yes' vendor='IBM'>z9BC-base</model>
<model usable='yes' vendor='IBM'>z9BC.2</model>
<model usable='yes' vendor='IBM'>z9BC.2-base</model>
<model usable='yes' vendor='IBM'>z9EC</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z9EC-base</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z9EC.2</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>z9EC.2-base</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>z9EC.3</model>
<model usable='yes' vendor='IBM'>z9EC.3-base</model>
cpu_s390: Implement getVendorForModel for IBM Z When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Boris Fiuczynski<fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-11-25 10:52:55 +00:00
<model usable='yes' vendor='IBM'>zBC12</model>
domain_capabilities: Sort CPU models Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-10-18 12:17:13 +00:00
<model usable='yes' vendor='IBM'>zBC12-base</model>
<model usable='yes' vendor='IBM'>zEC12</model>
<model usable='yes' vendor='IBM'>zEC12-base</model>
<model usable='yes' vendor='IBM'>zEC12.2</model>
<model usable='yes' vendor='IBM'>zEC12.2-base</model>
tests: add capabilities for QEMU 5.2.0 on s390x Let us introduce the xml and reply files for QEMU 5.2.0 on s390x. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-15 10:46:25 +00: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 12:18:05 +00:00
<memoryBacking supported='yes'>
<enum name='sourceType'>
<value>file</value>
<value>anonymous</value>
<value>memfd</value>
</enum>
</memoryBacking>
tests: add capabilities for QEMU 5.2.0 on s390x Let us introduce the xml and reply files for QEMU 5.2.0 on s390x. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-15 10:46:25 +00: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>
</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>egl-headless</value>
</enum>
</graphics>
<video supported='yes'>
<enum name='modelType'>
<value>virtio</value>
<value>none</value>
</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>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>
<value>builtin</value>
</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 12:50:51 +00: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 17:18:36 +00:00
<tpm supported='no'/>
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-30 21:29:14 +00: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-02 22:22:31 +00:00
<channel supported='yes'>
<enum name='type'>
<value>pty</value>
<value>unix</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 01:46:51 +00: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 08:31:45 +00:00
<interface supported='yes'>
<enum name='backendType'>
<value>default</value>
</enum>
</interface>
qemu: Report supported panic device models in domcapabilities Domain capabilities include information about support for various devices and models. Panic devices are not included in the output which means that management applications need to include the logic for choosing the right device model or request a default model and try defining such a domain. Add reporting of panic device models into the domain capabilities based on the logic in qemuValidateDomainDefPanic() and also report whether panic devices are supported based on whether at least one model is supported. That way consumers of the domain capability XML can differentiate between libvirt not reporting the panic device models or no model being supported. Resolves: https://issues.redhat.com/browse/RHEL-65187 Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-11-01 09:25:49 +00:00
<panic supported='yes'>
<enum name='model'>
<value>s390</value>
</enum>
</panic>
tests: add capabilities for QEMU 5.2.0 on s390x Let us introduce the xml and reply files for QEMU 5.2.0 on s390x. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-15 10:46:25 +00:00
</devices>
<features>
<gic supported='no'/>
<vmcoreinfo supported='no'/>
<genid supported='no'/>
<backingStoreInput supported='yes'/>
<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 15:12:08 +00:00
<async-teardown supported='no'/>
conf: Add availability of s390-pv in domain capabilities Adding availability of s390-pv in domain capabilities and adjust tests. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-07-16 09:44:32 +00:00
<s390-pv supported='no'/>
qemu: Expose availability of PS/2 feature in domcaps This advertises the feature only for the architectures and machine types where it can actually be used. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-08-28 12:26:25 +00:00
<ps2 supported='no'/>
tests: add capabilities for QEMU 5.2.0 on s390x Let us introduce the xml and reply files for QEMU 5.2.0 on s390x. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-15 10:46:25 +00: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 01:21:22 +00: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 08:45:43 +00:00
<launchSecurity supported='no'/>
tests: add capabilities for QEMU 5.2.0 on s390x Let us introduce the xml and reply files for QEMU 5.2.0 on s390x. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-12-15 10:46:25 +00:00
</features>
</domainCapabilities>
Reference in New Issue Copy Permalink