shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-03-09 20:58:33 +03:00
Code Releases Activity
libvirt/tests/cputestdata/x86_64-host+guest,models-result.xml

18 lines
687 B
XML
Raw Normal View History

Add support for cpu mode attribute The mode can be either of "custom" (default), "host-model", "host-passthrough". The semantics of each mode is described in the following examples: - guest CPU is a default model with specified topology: <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu> - guest CPU matches selected model: <cpu mode='custom' match='exact'> <model>core2duo</model> </cpu> - guest CPU should be a copy of host CPU as advertised by capabilities XML (this is a short cut for manually copying host CPU specification from capabilities to domain XML): <cpu mode='host-model'/> In case a hypervisor does not support the exact host model, libvirt automatically falls back to a closest supported CPU model and removes/adds features to match host. This behavior can be disabled by <cpu mode='host-model'> <model fallback='forbid'/> </cpu> - the same as previous returned by virDomainGetXMLDesc with VIR_DOMAIN_XML_UPDATE_CPU flag: <cpu mode='host-model' match='exact'> <model fallback='allow'>Penryn</model> --+ <vendor>Intel</vendor> | <topology sockets='2' cores='4' threads='1'/> + copied from <feature policy='require' name='dca'/> | capabilities XML <feature policy='require' name='xtpr'/> | ... --+ </cpu> - guest CPU should be exactly the same as host CPU even in the aspects libvirt doesn't model (such domain cannot be migrated unless both hosts contain exactly the same CPUs): <cpu mode='host-passthrough'/> - the same as previous returned by virDomainGetXMLDesc with VIR_DOMAIN_XML_UPDATE_CPU flag: <cpu mode='host-passthrough' match='minimal'> <model>Penryn</model> --+ copied from caps <vendor>Intel</vendor> | XML but doesn't <topology sockets='2' cores='4' threads='1'/> | describe all <feature policy='require' name='dca'/> | aspects of the <feature policy='require' name='xtpr'/> | actual guest CPU ... --+ </cpu>
2011-08-18 12:14:36 +02:00
<cpu mode='custom' match='exact'>
cpu: Optionally forbid fallback CPU models In case a hypervisor doesn't support the exact CPU model requested by a domain XML, we automatically fallback to a closest CPU model the hypervisor supports (and make sure we add/remove any additional features if needed). This patch adds 'fallback' attribute to model element, which can be used to disable this automatic fallback.
2011-12-21 14:27:16 +01:00
<model fallback='allow'>Nehalem</model>
conf: add support for specifying CPU "dies" parameter Recently CPU hardware vendors have started to support a new structure inside the CPU package topology known as a "die". Thus the hierarchy is now: sockets > dies > cores > threads This adds support for "dies" in the XML parser, with the value defaulting to 1 if not specified for backwards compatibility. For example a system with 64 logical CPUs might report <topology sockets="4" dies="2" cores="4" threads="2"/> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-16 11:16:51 +00:00
<topology sockets='2' dies='1' cores='4' threads='1'/>
cputest: Don't test cpuGuestData The API is no longer used anywhere else since it was replaced by a much saner work flow utilizing new APIs that work on virCPUDefPtr directly: virCPUCompare, virCPUUpdate, and virCPUTranslate. Not testing the new work flow caused some bugs to be hidden. This patch reveals them, but doesn't attempt to fix them. To make sure all test still pass after this patch, all affected test results are modified to pretend the tests succeeded. All of the bugs will be fixed in the following commits and the artificial modifications will be reverted. The following is the list of bugs in the new CPU model work flow: - a guest CPU with mode='custom' and missing <vendor/> gets the vendor copied from host's CPU (the vendor should only be copied to host-model CPUs): DO_TEST_UPDATE("x86", "host", "min", VIR_CPU_COMPARE_IDENTICAL) DO_TEST_UPDATE("x86", "host", "pentium3", VIR_CPU_COMPARE_IDENTICAL) DO_TEST_GUESTCPU("x86", "host-better", "pentium3", NULL, 0) - when a guest CPU with mode='custom' needs to be translated into another model because the original model is not supported by a hypervisor, the result will have its vendor set to the vendor of the original CPU model as specified in cpu_map.xml even if the original guest CPU XML didn't contain <vendor/>: DO_TEST_GUESTCPU("x86", "host", "guest", model486, 0) DO_TEST_GUESTCPU("x86", "host", "guest", models, 0) DO_TEST_GUESTCPU("x86", "host-Haswell-noTSX", "Haswell-noTSX", haswell, 0) - legacy POWERx_v* model names are not recognized: DO_TEST_GUESTCPU("ppc64", "host", "guest-legacy", ppc_models, 0) Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-10 09:41:17 +01:00
<feature policy='force' name='pbe'/>
<feature policy='force' name='monitor'/>
cpu_x86: Use array of features in CPU map There's no reason for keeping the features in a linked list. Especially when we know upfront the total number of features we are loading. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-05-17 15:15:40 +02:00
<feature policy='require' name='xtpr'/>
<feature policy='require' name='dca'/>
cputest: Don't test cpuGuestData The API is no longer used anywhere else since it was replaced by a much saner work flow utilizing new APIs that work on virCPUDefPtr directly: virCPUCompare, virCPUUpdate, and virCPUTranslate. Not testing the new work flow caused some bugs to be hidden. This patch reveals them, but doesn't attempt to fix them. To make sure all test still pass after this patch, all affected test results are modified to pretend the tests succeeded. All of the bugs will be fixed in the following commits and the artificial modifications will be reverted. The following is the list of bugs in the new CPU model work flow: - a guest CPU with mode='custom' and missing <vendor/> gets the vendor copied from host's CPU (the vendor should only be copied to host-model CPUs): DO_TEST_UPDATE("x86", "host", "min", VIR_CPU_COMPARE_IDENTICAL) DO_TEST_UPDATE("x86", "host", "pentium3", VIR_CPU_COMPARE_IDENTICAL) DO_TEST_GUESTCPU("x86", "host-better", "pentium3", NULL, 0) - when a guest CPU with mode='custom' needs to be translated into another model because the original model is not supported by a hypervisor, the result will have its vendor set to the vendor of the original CPU model as specified in cpu_map.xml even if the original guest CPU XML didn't contain <vendor/>: DO_TEST_GUESTCPU("x86", "host", "guest", model486, 0) DO_TEST_GUESTCPU("x86", "host", "guest", models, 0) DO_TEST_GUESTCPU("x86", "host-Haswell-noTSX", "Haswell-noTSX", haswell, 0) - legacy POWERx_v* model names are not recognized: DO_TEST_GUESTCPU("ppc64", "host", "guest-legacy", ppc_models, 0) Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-10 09:41:17 +01:00
<feature policy='force' name='3dnowext'/>
<feature policy='force' name='svm'/>
tests: Add unit tests for internal CPU APIs
2010-10-07 16:35:17 +02:00
<feature policy='disable' name='sse'/>
cpu_x86: Use array of features in CPU map There's no reason for keeping the features in a linked list. Especially when we know upfront the total number of features we are loading. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-05-17 15:15:40 +02:00
<feature policy='disable' name='sse4.2'/>
cputest: Don't test cpuGuestData The API is no longer used anywhere else since it was replaced by a much saner work flow utilizing new APIs that work on virCPUDefPtr directly: virCPUCompare, virCPUUpdate, and virCPUTranslate. Not testing the new work flow caused some bugs to be hidden. This patch reveals them, but doesn't attempt to fix them. To make sure all test still pass after this patch, all affected test results are modified to pretend the tests succeeded. All of the bugs will be fixed in the following commits and the artificial modifications will be reverted. The following is the list of bugs in the new CPU model work flow: - a guest CPU with mode='custom' and missing <vendor/> gets the vendor copied from host's CPU (the vendor should only be copied to host-model CPUs): DO_TEST_UPDATE("x86", "host", "min", VIR_CPU_COMPARE_IDENTICAL) DO_TEST_UPDATE("x86", "host", "pentium3", VIR_CPU_COMPARE_IDENTICAL) DO_TEST_GUESTCPU("x86", "host-better", "pentium3", NULL, 0) - when a guest CPU with mode='custom' needs to be translated into another model because the original model is not supported by a hypervisor, the result will have its vendor set to the vendor of the original CPU model as specified in cpu_map.xml even if the original guest CPU XML didn't contain <vendor/>: DO_TEST_GUESTCPU("x86", "host", "guest", model486, 0) DO_TEST_GUESTCPU("x86", "host", "guest", models, 0) DO_TEST_GUESTCPU("x86", "host-Haswell-noTSX", "Haswell-noTSX", haswell, 0) - legacy POWERx_v* model names are not recognized: DO_TEST_GUESTCPU("ppc64", "host", "guest-legacy", ppc_models, 0) Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-10 09:41:17 +01:00
<feature policy='forbid' name='popcnt'/>
<feature policy='disable' name='3dnow'/>
<feature policy='require' name='ssse3'/>
<feature policy='disable' name='vmx'/>
<feature policy='disable' name='ds_cpl'/>
tests: Add unit tests for internal CPU APIs
2010-10-07 16:35:17 +02:00
</cpu>
Copy Permalink