aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Removed more AMD-specific features from cpu64-rhel* modelsMartin Kletzander2012-03-091-2/+1
| | | | | | | We found few more AMD-specific features in cpu64-rhel* models that made it impossible to start qemu guest on Intel host (with this setting) even though qemu itself starts correctly with them. This impacts one test, thus the fix in tests/cputestdata/.
* x86: add kvm32 and kvm64, update qemu64Paolo Bonzini2012-01-272-4/+2
| | | | | | | | | | | | | Recently (or not so recently) QEMU added the kvm32 and kvm64 architectures, representing a least common denominator of all hosts that can run KVM. Add them to the machine map. Also, some features that TCG supports were added to qemu64. Add them to the cpu_map.xml whenever KVM is guaranteed to support those. We still have to leave some out, because they would not be available to guests running on older hosts. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* cpu: Update guest CPU in host-* modeJiri Denemark2012-01-177-0/+80
| | | | | | | VIR_DOMAIN_XML_UPDATE_CPU flag for virDomainGetXMLDesc may be used to get updated custom mode guest CPU definition in case it depends on host CPU. This patch implements the same behavior for host-model and host-passthrough CPU modes.
* Add support for cpu mode attributeJiri Denemark2012-01-1718-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cpu: Optionally forbid fallback CPU modelsJiri Denemark2012-01-1719-18/+36
| | | | | | | | 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.
* tests: Add unit tests for internal CPU APIsJiri Denemark2010-12-0151-0/+593