每個hypervisor對於guest能看到的cpu model定義都不同，Xen 提供host pass through，所以guest能看到的cpu和host完全相同。
QEMU/KVM中guest能看到自定義的通用cpu model “qemu32” or “qemu64”，而VMWare 要高級一些，它把host cpu划分成組，guest
能看到每組的baseline CPU model，這樣guest就能在改組遷移。
每種CPU models都采用不同方式來暴露其architecture ，比如x86采用CPUID instruction來暴露其cpu的capabilities 。
VMWare and Xen 就直接把CPUID instruction暴露給guest，但QEMU/KVM 不僅僅支持x86，所以不能采用這種方式。
Libvirt采用baseline CPU CPUID +features的方式，其中baseline CPU CPUID是每種CPU model的最大公共子集。
比如某laptop上的cpu信息，一共擁有20個features：
# virsh capabilities <capabilities> <host> <cpu> <arch>i686</arch> <model>pentium3</model> <topology sockets='1' cores='2' threads='1'/> <feature name='lahf_lm'/> <feature name='lm'/> <feature name='xtpr'/> <feature name='cx16'/> <feature name='ssse3'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='pni'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='sse2'/> <feature name='acpi'/> <feature name='ds'/> <feature name='clflush'/> <feature name='apic'/> </cpu> ...snip...
我們知道了libvirt如何描述cpu model和指令集，現在的問題就是暴露哪些CPU capabilities給guest。
如果數據中心中所有的cpu都是完全相同的，那么可以使用host pass through。
如果不是得話，那么久需要暴露這些cpu的公共子集。
Libvirt api提供了這些功能，把描述cpu的xml傳給libvirt，它會計算出這些cpu的公共子集。
比如在另外一台server上：
<capabilities>
<host>
<cpu>
<arch>x86_64</arch>
<model>phenom</model>
<topology sockets='2' cores='4' threads='1'/>
<feature name='osvw'/>
<feature name='3dnowprefetch'/>
<feature name='misalignsse'/>
<feature name='sse4a'/>
<feature name='abm'/>
<feature name='cr8legacy'/>
<feature name='extapic'/>
<feature name='cmp_legacy'/>
<feature name='lahf_lm'/>
<feature name='rdtscp'/>
<feature name='pdpe1gb'/>
<feature name='popcnt'/>
<feature name='cx16'/>
<feature name='ht'/>
<feature name='vme'/>
</cpu>
...snip...
計算該cpu是否與latptop上的cpu兼容：
$ ./tools/virsh cpu-compare cpu-server.xml
CPU described in cpu-server.xml is incompatible with host CPU
結果是不兼容因為laptop上有些指令集在server是沒有。
要找到他們的子集：
# virsh cpu-baseline both-cpus.xml <cpu match='exact'> <model>pentium3</model> <feature policy='require' name='lahf_lm'/> <feature policy='require' name='lm'/> <feature policy='require' name='cx16'/> <feature policy='require' name='monitor'/> <feature policy='require' name='pni'/> <feature policy='require' name='ht'/> <feature policy='require' name='sse2'/> <feature policy='require' name='clflush'/> <feature policy='require' name='apic'/> </cpu>
子集中只有9個features。
https://www.berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-qemukvm/
關於guest cpu模型的詳細參數：
Table 21.9. CPU model and topology elements
| Element | Description |
|---|---|
<cpu> |
This element contains all parameters for the vCPU feature set. |
<match> |
Specifies how closely the features indicated in the <cpu> element must match the vCPUs that are available. The match attribute can be omitted if <topology> is the only element nested in the <cpu>element. Possible values for the match attribute are:
match attribute is omitted from the <cpu>element, the default setting match='exact' is used. |
<mode> |
This optional attribute may be used to make it easier to configure a guest virtual machine CPU to be as close to the host physical machine CPU as possible. Possible values for the mode attribute are:
|
<model> |
Specifies CPU model requested by the guest virtual machine. The list of available CPU models and their definition can be found in cpu_map.xml file installed in libvirt's data directory. If a hypervisor is not able to use the exact CPU model, libvirt automatically falls back to a closest model supported by the hypervisor while maintaining the list of CPU features. An optional fallback attribute can be used to forbid this behavior, in which case an attempt to start a domain requesting an unsupported CPU model will fail. Supported values for fallback attribute are: allow (this is the default), and forbid. The optional vendor_id attribute can be used to set the vendor id seen by the guest virtual machine. It must be exactly 12 characters long. If not set, the vendor id of the host physical machine is used. Typical possible values are AuthenticAMD and GenuineIntel. |
<vendor> |
Specifies CPU vendor requested by the guest virtual machine. If this element is missing, the guest virtual machine runs on a CPU matching given features regardless of its vendor. The list of supported vendors can be found in cpu_map.xml. |
<topology> |
Specifies requested topology of virtual CPU provided to the guest virtual machine. Three non-zero values have to be given for sockets, cores, and threads: total number of CPU sockets, number of cores per socket, and number of threads per core, respectively. |
<feature> |
Can contain zero or more elements used to fine-tune features provided by the selected CPU model. The list of known feature names can be found in the same file as CPU models. The meaning of each feature element depends on its policy attribute, which has to be set to one of the following values:
|