Raison NMI 20 et 30 inconnue sur une machine virtuelle

J'ai tiré la console sur une machine virtuelle que je gère aujourd'hui et j'ai été accueilli avec quelques messages du noyau:

[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

Ce n'est que quelques-uns d'entre eux, les 20 et 30 se produisent sur les CPU 0 et 1.

La VM est Debian Jessie, démarrage du BIOS ("PC standard QEMU (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014"; noyau 3.16.0-4-amd64)
L'hyperviseur est libvirt / KVM exécuté sur les tests Debian (actuellement 4.7.0-1-amd64 de Debian; qemu 1: 2.7 + dfsg-3).
Le matériel est un Opteron 6344 sur un Supermicro H8SGL-F avec RAM ECC avec scrub activé.

Je ne vois aucun message d'erreur / d'avertissement NMI ou EDAC sur l'hôte.

Une idée de la cause de ces messages NMI sur l'invité? Faut-il s'inquiéter?

(Peut être lié à un NMI reçu pour une raison inconnue 20 - Avez-vous un étrange mode d'économie d'énergie activé? Mais cela semble être du métal nu).

— derobert
source

Je me demande si cela aiderait à passer au noyau des VMsnoapic apci=off

— Rui F Ribeiro

@RuiFRibeiro Eh bien, actuellement, la machine virtuelle fonctionne sans aucun problème (apparent). Il est en production, donc je préfère ne pas recommencer à redémarrer pour essayer des options de noyau aléatoires juste pour voir. Ce serait une autre histoire si elle était d'aider un noyau dev pour déboguer le problème, etc. ( De plus, il est pas comme ils sont fréquents-it'd prendre un certain temps pour être sûr.)

— derobert

J'essaie de retrouver le même problème depuis un certain temps. Certains points de données qui peuvent être utiles sont: la version du noyau hôte, la version qemu, si la machine virtuelle utilise le démarrage BIOS ou UEFI, si la machine virtuelle utilise i440fx ou q35.

— Michael Hampton

@MichaelHampton a demandé que des détails soient ajoutés à la question.

— derobert

J'ai le même problème, voici les détails (très similaires en fait): VM est Debian Jessie (3.16.0-4-amd64) avec BIOS 1.7.5-20140531_083030-gandalf (04/01/2014). L'hyperviseur est libvirt / KVM sur Debian Jessie, mais avec un noyau rétroporté (4.7.0-0.bpo.1-amd64). Le matériel de l'hyperviseur est deux Opteron 6272, avec ECC RAM (carte mère actuellement inconnue, mais probablement Supermicro d'une certaine sorte). Étant donné que ces détails sont remarquablement similaires à ceux de Derobert, je ne suis pas trop surpris de rencontrer ce problème aussi, mais j'espère qu'ils aideront.

— jvperrin

Réponses:

J'ai eu le même problème en utilisant une configuration similaire:

Processeur AMD (bien que j'aie vu des rapports du même problème avec les processeurs Intel, mais aucun de mes hyperviseurs fonctionnant sur les processeurs Intel n'a ce problème, même avec le passthrough du processeur activé).
Debian, noyau 4.x sur l'hyperviseur et l'invité (4.9.0-4-amd64 dans mon cas sur les deux).

Ma solution a été de changer ma machine virtuelle invitée pour utiliser un processeur émulé QEMU plutôt qu'un relais CPU. Cela a entraîné la suppression de la <cpu mode='host-passthrough'/>ligne du fichier de définition d'invité.

Mise à jour : j'ai fait une enquête plus approfondie et les éléments gênants étaient sous l' clockélément:

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

La vraie solution était de supprimer les trois <timer>éléments, après quoi ils <cpu mode='host-passthrough'/>pouvaient être réactivés.

Pour être complet, j'ai ajouté une réponse similaire à la question liée .

— mjturner
source

Ces trois éléments sont des valeurs par défaut, les désactiver ne devrait précisément rien faire et les rajouter lors de la sauvegarde.

— Simon Richter

Le problème semble être que la fin de l'interruption n'est pas communiquée correctement.

Pour libvirt, assurez-vous qu'il eoiest activé:

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

Sur la ligne de commande pour KVM qui se traduit par

-cpu …,+kvm_pv_eoi

Cela semble fonctionner pour nous avec -M q35, le passthrough de l'hôte cpu et la configuration par défaut sinon (interruptions RTC en file d'attente, interruptions PIT abandonnées, HPET indisponible).

— Simon Richter
source

J'ai eu le même problème sur Debian 9et Qemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5).
Je l'ai résolu en remplaçant le modèle de carte vidéo de virtioà cirrus(ou vous pouvez essayer d'utiliser un autre modèle de la qemupage de manuel).

— Oleg Golovanov
source