Motivo desconocido de NMI 20 y 30 en una VM

10

Abrí la consola en una máquina virtual que administro hoy y me saludaron con algunos mensajes 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

Son solo algunos de ellos, tanto 20 como 30 ocurren en la CPU 0 y 1.

  • VM es 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 es libvirt / KVM que se ejecuta en las pruebas de Debian (actualmente Debian 4.7.0-1-amd64; qemu 1: 2.7 + dfsg-3).
  • El hardware es un Opteron 6344 en un Supermicro H8SGL-F con RAM ECC con scrub habilitado.

No veo ningún mensaje de error / advertencia de NMI o EDAC en el host.

¿Alguna idea de lo que está causando estos mensajes NMI en el invitado? ¿Hay algo de qué preocuparse?

(Puede estar relacionado con el NMI recibido por una razón desconocida 20: ¿tiene habilitado un modo de ahorro de energía extraño? Pero parece ser un metal desnudo).

linux kvm libvirt nmi derobert
fuente
Me pregunto si sería útil pasar al núcleo de las máquinas virtualesnoapic apci=off
Rui F Ribeiro
@RuiFRibeiro Bueno, actualmente la VM funciona sin ningún problema (aparente). Está en producción, por lo que prefiero no reiniciar para probar opciones de kernel aleatorias solo para ver. Sería una historia diferente si fuera para ayudar a un desarrollador de kernel a depurar el problema, etc. (Además, no es que sean frecuentes, tomaría un tiempo estar seguro.)
derobert
He estado tratando de localizar el mismo problema por algún tiempo. Algunos puntos de datos que pueden ser útiles son: versión del núcleo del host, versión qemu, si la VM usa BIOS o arranque UEFI, si la VM usa i440fx o q35.
Michael Hampton
@MichaelHampton solicitó detalles agregados a la pregunta.
derobert
Tengo el mismo problema, aquí están los detalles (muy similares en realidad): VM es Debian jessie (3.16.0-4-amd64) con BIOS 1.7.5-20140531_083030-gandalf (01/04/2014). El hipervisor es libvirt / KVM en Debian jessie, pero con kernel compatible (4.7.0-0.bpo.1-amd64). El hardware del hipervisor son dos Opteron 6272, con RAM ECC (placa base actualmente desconocida, pero probablemente Supermicro de algún tipo). Dado que estos detalles son notablemente similares a los de Derobert, no estoy demasiado sorprendido de que encuentre este problema también, pero espero que ayuden.
jvperrin

Respuestas:

2

Tuve el mismo problema al usar una configuración similar:

  1. CPU AMD (aunque he visto informes del mismo problema con las CPU Intel, pero ninguno de mis hipervisores que se ejecutan en las CPU Intel tiene este problema, incluso con el paso de CPU habilitado).
  2. Debian, kernel 4.x en el hipervisor e invitado (4.9.0-4-amd64 en mi caso en ambos).

Mi solución fue cambiar mi máquina virtual invitada para usar una CPU emulada QEMU en lugar de una transferencia de CPU. Esto implicaba eliminar la <cpu mode='host-passthrough'/>línea del archivo de definición de invitado.

Actualización : Investigué más y los elementos problemáticos estaban debajo del clockelemento:

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

La solución real era eliminar los tres <timer>elementos, después de lo cual <cpu mode='host-passthrough'/>podría habilitarse nuevamente.

Para completar, agregué una respuesta similar a la pregunta vinculada .

mjturner
fuente
Estos tres elementos son valores predeterminados, deshabilitarlos no debería hacer nada y volver a agregarlos al guardar.
Simon Richter
1

El problema parece ser que el fin de la interrupción no se comunica correctamente.

Para libvirt, asegúrese de que eoiesté habilitado:

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

En la línea de comando para KVM que se traduce en

-cpu …,+kvm_pv_eoi

Esto parece funcionar para nosotros con el -M q35paso de CPU de host y la configuración predeterminada de lo contrario (interrupciones RTC en cola, interrupciones PIT caídas, HPET no disponible).

Simon Richter
fuente
0

He tenido el mismo problema en Debian 9y Qemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5).
Lo resolví reemplazando el modelo de tarjeta de video de virtioa cirrus(o puede intentar usar otro modelo de la qemupágina de manual).

Oleg Golovanov
fuente