Unbekannter NMI-Grund 20 und 30 auf einer VM

Ich habe die Konsole auf einer virtuellen Maschine aufgerufen, die ich heute verwalte, und wurde mit einigen Kernel-Nachrichten begrüßt:

[5912557.130943] Uhhuh. NMI received for unknown reason 20 on CPU 0.
[5912557.131115] Do you have a strange power saving mode enabled?
[5912557.131287] Dazed and confused, but trying to continue
[6064281.393568] Uhhuh. NMI received for unknown reason 30 on CPU 1.
[6064281.393888] Do you have a strange power saving mode enabled?
[6064281.394235] Dazed and confused, but trying to continue

Das sind nur einige davon, sowohl 20 als auch 30 treten auf CPU 0 und 1 auf.

VM ist Debian Jessie, BIOS-Boot ("QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014"; Kernel 3.16.0-4-amd64)
Hypervisor ist libvirt / KVM, das unter Debian-Tests ausgeführt wird (derzeit Debians 4.7.0-1-amd64; qemu 1: 2.7 + dfsg-3).
Hardware ist ein Opteron 6344 auf einem Supermicro H8SGL-F mit ECC-RAM mit aktiviertem Scrub.

Ich sehe keine NMI- oder EDAC-Fehler- / Warnmeldungen auf dem Host.

Irgendeine Idee, was diese NMI-Nachrichten beim Gast verursacht? Sind sie etwas, worüber sie sich Sorgen machen müssen?

( Kann mit NMI zusammenhängen, das aus einem unbekannten Grund empfangen wurde. 20 - Haben Sie einen seltsamen Energiesparmodus aktiviert? Aber das scheint Bare Metal zu sein.)

— derobert
quelle

Ich frage mich, ob es helfen würde, zum Kernel der VMs überzugehennoapic apci=off

— Rui F Ribeiro

@RuiFRibeiro Nun, derzeit funktioniert die VM ohne (offensichtliche) Probleme. Es befindet sich in der Produktion, daher möchte ich lieber nicht neu starten, um zufällige Kerneloptionen auszuprobieren, nur um zu sehen. Wäre eine andere Geschichte, wenn es einem Kernel-Entwickler helfen würde, das Problem usw. zu debuggen. (Außerdem ist es nicht so, dass sie häufig auftreten

— würde

Ich habe seit einiger Zeit versucht, das gleiche Problem aufzuspüren. Einige Datenpunkte, die hilfreich sein können, sind: Host-Kernel-Version, QEMU-Version, ob die VM BIOS- oder UEFI-Boot verwendet, ob die VM i440fx oder Q35 verwendet.

— Michael Hampton

@MichaelHampton hat Details angefordert, die der Frage hinzugefügt wurden.

— Derobert

Ich habe das gleiche Problem, hier sind die Details (eigentlich sehr ähnlich): VM ist Debian Jessie (3.16.0-4-amd64) mit BIOS 1.7.5-20140531_083030-gandalf (04/01/2014). Hypervisor ist libvirt / KVM auf Debian Jessie, jedoch mit einem Backport-Kernel (4.7.0-0.bpo.1-amd64). Bei der Hypervisor-Hardware handelt es sich um zwei Opteron 6272 mit ECC-RAM (Motherboard derzeit unbekannt, aber wahrscheinlich Supermicro). Angesichts der Tatsache, dass diese Details den von Derobert bemerkenswert ähnlich sind, bin ich nicht allzu überrascht, dass ich auch auf dieses Problem stoße, aber hoffentlich helfen sie.

— Jvperrin

Antworten:

Ich hatte das gleiche Problem mit einem ähnlichen Setup:

AMD-CPU (obwohl ich Berichte über dasselbe Problem mit Intel-CPUs gesehen habe, aber keiner meiner Hypervisoren, die auf Intel-CPUs ausgeführt werden, hat dieses Problem, selbst wenn der CPU-Passthrough aktiviert ist).
Debian, Kernel 4.x auf dem Hypervisor und Gast (4.9.0-4-amd64 in meinem Fall auf beiden).

Meine Lösung bestand darin, meine Gast-VM so zu wechseln, dass sie eine QEMU-emulierte CPU anstelle eines CPU-Passthrough verwendet. Dies beinhaltete das Entfernen der <cpu mode='host-passthrough'/>Zeile aus der Gastdefinitionsdatei.

Update : Ich habe weitere Untersuchungen durchgeführt und die störenden Elemente befanden sich unter dem clockElement:

<clock offset='utc'>
  <timer name='rtc' tickpolicy='catchup'/>
  <timer name='pit' tickpolicy='delay'/>
  <timer name='hpet' present='no'/>
</clock>

Die eigentliche Lösung bestand darin, die drei <timer>Elemente zu entfernen , wonach <cpu mode='host-passthrough'/>sie wieder aktiviert werden konnten.

Der Vollständigkeit halber habe ich der verknüpften Frage eine ähnliche Antwort hinzugefügt .

— mjturner
quelle

Diese drei Elemente sind Standardwerte. Wenn Sie sie deaktivieren, sollten Sie genau nichts tun und sie beim Speichern erneut hinzufügen.

— Simon Richter

Das Problem scheint zu sein, dass das Ende des Interrupts nicht richtig kommuniziert wird.

Stellen Sie für libvirt sicher, dass eoiaktiviert ist:

<domain>
  …
  <features>
    <apic eoi='on'/>
    …

In der Befehlszeile für KVM, die übersetzt wird

-cpu …,+kvm_pv_eoi

Dies scheint für uns mit -M q35Host-CPU-Passthrough und Standardkonfiguration ansonsten zu funktionieren (RTC-Interrupts in der Warteschlange, PIT-Interrupts gelöscht, HPET nicht verfügbar).

— Simon Richter
quelle

Ich hatte das gleiche Problem auf Debian 9und Qemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5).
Ich habe es behoben, indem ich das Videokartenmodell von virtiobis ersetzt habe cirrus(oder Sie können versuchen, ein anderes Modell von der qemuManpage aus zu verwenden).

— Oleg Golovanov
quelle