Motivo NMI sconosciuto 20 e 30 su una macchina virtuale

Ho richiamato la console su una macchina virtuale che gestisco oggi e sono stato accolto con alcuni messaggi del kernel:

[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

Sono solo alcuni di questi, sia 20 che 30 si verificano sulla CPU 0 e 1.

VM è Debian Jessie, avvio del BIOS ("PC standard QEMU (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014"; kernel 3.16.0-4-amd64)
Hypervisor è libvirt / KVM in esecuzione su test Debian (attualmente Debian 4.7.0-1-amd64; qemu 1: 2.7 + dfsg-3).
L'hardware è un Opteron 6344 su un Supermicro H8SGL-F con RAM ECC con scrub abilitato.

Non vedo alcun messaggio di errore / avviso NMI o EDAC sull'host.

Hai idea di cosa sta causando questi messaggi NMI sul guest? Sono qualcosa di cui preoccuparsi?

(Può essere correlato all'NMI ricevuto per un motivo sconosciuto 20 - È stata attivata una strana modalità di risparmio energetico? Ma sembra essere completamente in metallo).

— derobert
fonte

Mi chiedo se sarebbe utile passare al kernel delle VMnoapic apci=off

— Rui F Ribeiro,

@RuiFRibeiro Bene, attualmente la VM funziona senza problemi (apparenti). È in produzione, quindi preferirei non riavviare per provare opzioni del kernel casuali solo per vedere. Sarebbe una storia diversa se aiutasse uno sviluppatore del kernel a eseguire il debug del problema, ecc. (Inoltre, non è come se fossero frequenti - ci vorrebbe un po 'di tempo per essere sicuri.)

— derobert

Ho cercato di rintracciare lo stesso problema per qualche tempo. Alcuni punti dati che possono essere utili sono: versione del kernel host, versione qemu, se la VM utilizza l'avvio BIOS o UEFI, se la VM utilizza i440fx o q35.

— Michael Hampton,

@MichaelHampton ha richiesto i dettagli aggiunti alla domanda.

— derobert il

Ho lo stesso problema, ecco i dettagli (in realtà molto simili): VM è Debian jessie (3.16.0-4-amd64) con BIOS 1.7.5-20140531_083030-gandalf (04/01/2014). Hypervisor è libvirt / KVM su Debian jessie, ma con kernel backported (4.7.0-0.bpo.1-amd64). L'hardware Hypervisor è due Opteron 6272, con RAM ECC (scheda madre attualmente sconosciuta, ma probabilmente Supermicro di qualche tipo). Dato che questi dettagli sono notevolmente simili a quelli di Derobert, non sono troppo sorpreso di incontrare anche questo problema, ma spero che possano aiutare.

— jvperrin,

Risposte:

Ho avuto lo stesso problema usando una configurazione simile:

CPU AMD (anche se ho visto segnalazioni dello stesso problema con le CPU Intel, ma nessuno dei miei hypervisor in esecuzione su CPU Intel presenta questo problema, anche con il passthrough CPU abilitato).
Debian, kernel 4.x sull'hypervisor e guest (4.9.0-4-amd64 nel mio caso su entrambi).

La mia soluzione era quella di cambiare la mia VM ospite per usare una CPU emulata QEMU anziché passthrough CPU. Ciò ha comportato la rimozione della <cpu mode='host-passthrough'/>linea dal file di definizione del guest.

Aggiornamento : ho fatto ulteriori indagini e gli elementi problematici erano sotto l' clockelemento:

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

La vera soluzione era quella di rimuovere i tre <timer>elementi, dopo di che <cpu mode='host-passthrough'/>potevano essere nuovamente abilitati.

Per completezza ho aggiunto una risposta simile alla domanda collegata .

— mjturner
fonte

Questi tre elementi sono valori predefiniti, disabilitandoli non dovrebbero fare esattamente nulla e aggiungerli di nuovo al momento del salvataggio.

— Simon Richter,

Il problema sembra essere che la fine dell'interruzione non sia comunicata correttamente.

Per libvirt, assicurati che eoisia abilitato:

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

Sulla riga di comando per KVM che si traduce in

-cpu …,+kvm_pv_eoi

Questo sembra funzionare con noi -M q35, host cpu passthrough e configurazione predefinita altrimenti (interruzioni RTC in coda, interruzioni PIT eliminate, HPET non disponibile).

— Simon Richter
fonte

Ho avuto lo stesso problema su Debian 9e Qemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5).
L'ho risolto sostituendo il modello videocard da virtioa cirrus(oppure puoi provare a usare un altro modello dalla qemupagina man).

— Oleg Golovanov
fonte