libvirt cpu-mode='host-model' confuses while mapping cpu models?

Question

I have physical host which has cpu model 'Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz' and it has 'avx2' flag in cpuinfo. The host has kvm/qemu hypervisor and libvirt configured. I set cpu mode as host-model in domain XML. Guest vm can be created on the host. When I check cpu model of guest vm, it shows as 'SandyBridge' and it also has 'avx2' flag in cpuinfo. But 'SandyBridge' does not support 'avx2' flag but 'Haswell' model does support. It is just due to host-model mode, libvirt finds nearest cpu model to 'Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz' as 'SandyBridge' but it should show 'Haswell' instead. Does that mean libvirt have a bug or it is valid representation in this scenario? I am using libvirt version 1.2.2

Answer 1

Within a particular chip generation (SandyBridge, Haswell, etc), Intel does not in fact guarantee that all different models it makes have the same CPU flags present. We can see this with Haswell or later where some CPUs have the TSX feature and some don't. QEMU/libvirt generally only provide a single model for each Intel generation though, so its possible that your physical CPU might not actually be compatible with the correspondingly named QEMU model.

From libvirt POV, the names are just a shortcut for a particular group of features. As such when identifying the CPU for "host-model" libvirt completely ignores names, and just looks for the CPU whose list of features is most closely related to your host CPU, and then lists any extra CPU features explicitly in the XML. So all this means that even though you have Haswell as your physical CPU, it is entirely possible that libvirt will display a different model name for your guest. There's nothing really wrong with this from a functional POV - the features should all be present still (except for a few that KVM intentionally blocks), it is merely a bit "surprising" to look at.

In your case, what I think is going on is due to the bug in Intel TSX support. This feature was introduced in Haswell, but then blocked in a microcode update after Intel found out it was broken. This causes the 'tsx' feature to disappear from the CPU model in your physical machine. The libvirt/QEMU Haswell CPU model still contains 'tsx', so this means libvirt won't match against your Haswell CPU. In libvirt >= 1.2.14, we introduced a new Haswell-noTSX CPU model to deall with this particular problem, but you say you only have 1.2.2. SandyBridge is simply the next best compatible CPU model that libvirt can find for you.

Answer 2

I found another workaround which doesn't require to upgrade libvirt. I removed hle and rtm flags from the definition of Haswell in cpu mapping xml file used by libvirt (/usr/share/libvirt/cpu_map.xml). And then I restarted libvirt process. Then I rebooted VM and it showed correct model name as Haswell.