- 29 1月, 2014 3 次提交
-
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1049391 The new tests would fail in various ways without the two previous commits.
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1049391 When all source CPU XMLs contain just a single CPU model (with a possibly varying set of additional feature elements), virConnectBaselineCPU will try to use this CPU model in the computed guest CPU. Thus, when used on just a single CPU (useful with VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES), the result will not use a different CPU model. If the computed CPU uses the source model, set fallback mode to 'forbid' to make sure the guest CPU will always be as close as possible to the source CPUs.
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1049391 virConnectBaselineCPU test results are now stored in different files depending on VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES.
-
- 17 8月, 2013 1 次提交
-
-
由 Don Dugger 提交于
Currently the virConnectBaselineCPU API does not expose the CPU features that are part of the CPU's model. This patch adds a new flag, VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, that causes the API to explicitly list all features that are part of that model. Signed-off-by: NDon Dugger <donald.d.dugger@intel.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 17 1月, 2012 2 次提交
-
-
由 Jiri Denemark 提交于
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>
-
由 Jiri Denemark 提交于
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.
-
- 01 12月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
-