libvirt cpu-mode = 'Host-Modell' verwirrt beim Mappen von CPU-Modellen?

Question

Ich habe physischen Host, der CPU-Modell 'Intel (R) Xeon (R) CPU E5-2670 v3 @ 2.30GHz' und es hat 'avx2' Flag in CPUinfo. Der Host hat kvm/qemu-Hypervisor und libvirt konfiguriert. Ich setze CPU-Modus als Host-Modell in Domain-XML. Guest vm kann auf dem Host erstellt werden. Wenn ich das cpu-Modell von guest vm überprüfe, wird es als 'SandyBridge' angezeigt und es hat auch 'avx2' in cpuinfo. Aber 'SandyBridge' unterstützt keine 'avx2' Flagge, aber 'Haswell' unterstützt. Aufgrund des Host-Modell-Modus findet libvirt das nächstgelegene CPU-Modell als 'SandyBridge' für 'Intel (R) Xeon (R) CPU E5-2670 v3 @ 2.30GHz', aber stattdessen sollte 'Haswell' angezeigt werden. Bedeutet das, dass libvirt einen Fehler oder eine gültige Darstellung in diesem Szenario hat? Ich benutze libvirt Version 1.2.2

Answer 1

Innerhalb einer bestimmten Chip-Generation (SandyBridge, Haswell, etc), Intel garantiert nicht, dass alle verschiedenen Modelle es die gleichen CPU-Flags vorhanden hat. Wir können dies mit Haswell oder später sehen, wo einige CPUs die TSX-Funktion haben und andere nicht. QEMU/libvirt stellt im Allgemeinen nur ein einzelnes Modell für jede Intel-Generation zur Verfügung, daher ist es möglich, dass Ihre physische CPU möglicherweise nicht mit dem entsprechend benannten QEMU-Modell kompatibel ist.

Von libvirt POV sind die Namen nur eine Abkürzung für eine bestimmte Gruppe von Features. Daher ignoriert libvirt beim Identifizieren der CPU für "Host-Modell" vollständig die Namen und sucht nur nach der CPU, deren Liste der Merkmale am ehesten mit Ihrer Host-CPU zusammenhängt, und listet alle zusätzlichen CPU-Funktionen explizit im XML auf. All dies bedeutet, dass, obwohl Sie Haswell als Ihre physische CPU haben, es durchaus möglich ist, dass libvirt einen anderen Modellnamen für Ihren Gast anzeigt. Von einem funktionalen POV ist nichts wirklich falsch - die Features sollten alle noch vorhanden sein (abgesehen von ein paar, die KVM absichtlich blockiert), es ist nur ein bisschen "überraschend" zu betrachten.

In Ihrem Fall, was ich denke, ist aufgrund der Fehler in der Intel TSX-Unterstützung. Dieses Feature wurde in Haswell eingeführt, aber dann in einem Mikrocode-Update blockiert, nachdem Intel herausgefunden hatte, dass es defekt war. Dies führt dazu, dass die 'tsx'-Funktion aus dem CPU-Modell in Ihrer physischen Maschine verschwindet. Das libvirt/QEMU Haswell-CPU-Modell enthält immer noch 'tsx'. Dies bedeutet, dass libvirt nicht mit Ihrer Haswell-CPU übereinstimmt. In libvirt> = 1.2.14 haben wir ein neues Haswell-noTSX-CPU-Modell eingeführt, um dieses spezielle Problem zu lösen, aber Sie sagen, Sie haben nur 1.2.2. SandyBridge ist einfach das nächstbeste kompatible CPU-Modell, das libvirt für Sie finden kann.

Answer 2

Ich fand eine andere Problemumgehung, die libvirt nicht aktualisieren muss. Ich habe hle und rtm flags aus der Definition von Haswell in der cpu mapping XML-Datei entfernt, die von libvirt (/usr/share/libvirt/cpu_map.xml) verwendet wird. Und dann habe ich den libvirt-Prozess neu gestartet. Dann startete ich VM neu und es zeigte korrekten Modellnamen wie Haswell.