Nieznany powód NMI 20 i 30 na maszynie wirtualnej

10

Podciągnąłem konsolę na maszynie wirtualnej, którą dziś zarządzam i przywitano mnie kilkoma komunikatami jądra:

[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

To tylko kilka z nich, zarówno 20, jak i 30 występują na CPU 0 i 1.

  • VM to Debian Jessie, rozruch systemu BIOS („QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014”; jądro 3.16.0-4-amd64)
  • Hypervisor to libvirt / KVM działający na testach Debiana (obecnie Debian 4.7.0-1-amd64; qemu 1: 2.7 + dfsg-3).
  • Sprzęt to Opteron 6344 na Supermicro H8SGL-F z ECC RAM z włączonym szorowaniem.

Nie widzę żadnych komunikatów o błędach / ostrzeżeniach NMI lub EDAC na hoście.

Masz pojęcie, co powoduje te komunikaty NMI u gościa? Czy mają się czym martwić?

(Może być związany z NMI otrzymanym z nieznanego powodu 20 - Czy masz włączony dziwny tryb oszczędzania energii? Ale wydaje się, że jest to czysty metal).

linux kvm libvirt nmi derobert
źródło
Zastanawiam się, czy pomogłoby to przejść do jądra maszyn wirtualnychnoapic apci=off
Rui F Ribeiro
@RuiFRibeiro Cóż, obecnie VM działa bez żadnych (pozornych) problemów. Jest w produkcji, więc wolałbym nie przestawiać się na ponowne uruchamianie, aby wypróbować losowe opcje jądra, żeby się przekonać. Byłoby inaczej, gdyby pomógł programistom jądra w debugowaniu problemu itp. (Plus, to nie tak, że są częste - zajęłoby to trochę czasu.)
derobert
Od jakiegoś czasu próbuję znaleźć ten sam problem. Niektóre punkty danych, które mogą być pomocne, to: wersja jądra hosta, wersja qemu, czy VM używa rozruchu BIOS lub UEFI, czy VM używa i440fx czy q35.
Michael Hampton
@MichaelHampton poprosił o dodanie szczegółów do pytania.
derobert
Mam ten sam problem, oto szczegóły (tak naprawdę bardzo podobne): VM to Debian jessie (3.16.0-4-amd64) z BIOSem 1.7.5-20140531_083030-gandalf (04/01/2014). Hypervisor to libvirt / KVM na Debianie jessie, ale z jądrem zportowanym (4.7.0-0.bpo.1-amd64). Sprzęt Hypervisora ​​to dwa Opteron 6272 z ECC RAM (płyta główna obecnie nieznana, ale prawdopodobnie pewnego rodzaju Supermicro). Biorąc pod uwagę, że te szczegóły są niezwykle podobne do tych derobertów, nie jestem zbyt zaskoczony, że napotykam ten problem, ale mam nadzieję, że pomogą.
jvperrin

Odpowiedzi:

2

Miałem ten sam problem przy użyciu podobnej konfiguracji:

  1. Procesor AMD (chociaż widziałem doniesienia o tym samym problemie z procesorami Intel, ale żaden z moich hiperwizorów działających na procesorach Intel nie ma tego problemu, nawet przy włączonym przekazywaniu CPU).
  2. Debian, jądro 4.x na hiperwizorze i guest (4.9.0-4-amd64 w moim przypadku na obu).

Moje rozwiązanie polegało na zmianie maszyny wirtualnej gościa na użycie procesora emulowanego przez QEMU zamiast przejścia przez procesor. Wiązało się to z usunięciem <cpu mode='host-passthrough'/>linii z pliku definicji gościa.

Aktualizacja : Przeprowadziłem dalsze dochodzenie, a kłopotliwe elementy były pod tym clockelementem:

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

Prawdziwym rozwiązaniem było usunięcie trzech <timer>elementów, po których <cpu mode='host-passthrough'/>można je ponownie włączyć.

Dla kompletności dodałem podobną odpowiedź na połączone pytanie .

mjturner
źródło
Te trzy elementy są wartościami domyślnymi, wyłączenie ich nie powinno robić nic i ponownie dodać je przy zapisywaniu.
Simon Richter
1

Problem polega na tym, że Koniec Przerwania nie jest poprawnie komunikowany.

W przypadku libvirt upewnij się, że eoijest włączony:

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

W wierszu polecenia KVM, który tłumaczy

-cpu …,+kvm_pv_eoi

Wydaje się, że działa to dla nas z -M q35, w innym przypadku przejście przez procesor hosta i domyślna konfiguracja (RTC przerywa w kolejce, przerwane PIT, HPET niedostępny).

Simon Richter
źródło
0

Miałem ten sam problem na Debian 9i Qemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5).
Rozwiązałem go, zastępując model karty wideo od virtiona cirrus(lub możesz spróbować użyć innego modelu ze qemustrony podręcznika ).

Oleg Golovanov
źródło