libvirt/tests/cputestdata/x86-host+guest,models-result.xml

<cpu mode='custom' match='exact'>
  <arch>x86_64</arch>
  <model fallback='allow'>Nehalem</model>
  <feature policy='require' name='pbe'/>
  <feature policy='require' name='monitor'/>
  <feature policy='require' name='xtpr'/>
  <feature policy='require' name='dca'/>
  <feature policy='require' name='3dnowext'/>
  <feature policy='require' name='svm'/>
  <feature policy='disable' name='sse'/>
  <feature policy='disable' name='sse4.2'/>
  <feature policy='disable' name='popcnt'/>
</cpu>
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 10:14:36 +00:00			`<cpu mode='custom' match='exact'>`
tests: Add unit tests for internal CPU APIs 2010-10-07 14:35:17 +00:00			`<arch>x86_64</arch>`
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 13:27:16 +00:00			`<model fallback='allow'>Nehalem</model>`
tests: Add unit tests for internal CPU APIs 2010-10-07 14:35:17 +00:00			`<feature policy='require' name='pbe'/>`
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 13:15:40 +00:00			`<feature policy='require' name='monitor'/>`
			`<feature policy='require' name='xtpr'/>`
			`<feature policy='require' name='dca'/>`
			`<feature policy='require' name='3dnowext'/>`
			`<feature policy='require' name='svm'/>`
tests: Add unit tests for internal CPU APIs 2010-10-07 14:35:17 +00: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 13:15:40 +00:00			`<feature policy='disable' name='sse4.2'/>`
			`<feature policy='disable' name='popcnt'/>`
tests: Add unit tests for internal CPU APIs 2010-10-07 14:35:17 +00:00			`</cpu>`