libvirt/tests/cputestdata/x86-host+guest.xml

<cpu mode='custom' match='exact'>
  <model fallback='allow'>Penryn</model>
  <topology sockets='2' cores='4' threads='1'/>
  <feature policy='require' name='dca'/>
  <feature policy='require' name='xtpr'/>
  <feature policy='disable' name='sse4.2'/>
  <feature policy='disable' name='3dnow'/>
  <feature policy='require' name='ssse3'/>
  <feature policy='disable' name='vmx'/>
  <feature policy='disable' name='ds_cpl'/>
  <feature policy='disable' name='sse'/>
  <feature policy='force' name='monitor'/>
  <feature policy='force' name='pbe'/>
  <feature policy='force' name='3dnowext'/>
  <feature policy='force' name='svm'/>
  <feature policy='forbid' 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'>`
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'>Penryn</model>`
tests: Add unit tests for internal CPU APIs 2010-10-07 14:35:17 +00:00			`<topology sockets='2' cores='4' threads='1'/>`
			`<feature policy='require' name='dca'/>`
			`<feature policy='require' name='xtpr'/>`
			`<feature policy='disable' name='sse4.2'/>`
			`<feature policy='disable' name='3dnow'/>`
			`<feature policy='require' name='ssse3'/>`
			`<feature policy='disable' name='vmx'/>`
			`<feature policy='disable' name='ds_cpl'/>`
			`<feature policy='disable' name='sse'/>`
			`<feature policy='force' name='monitor'/>`
			`<feature policy='force' name='pbe'/>`
			`<feature policy='force' name='3dnowext'/>`
			`<feature policy='force' name='svm'/>`
			`<feature policy='forbid' name='popcnt'/>`
			`</cpu>`