VMでの不明なNMI理由20および30

今日管理している仮想マシンのコンソールを引き上げると、いくつかのカーネルメッセージが表示されました。

[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

それはそれらのほんの一部です、20と30の両方がCPU 0と1で発生します。

VMはDebian Jessie、BIOSブート（「QEMU標準PC（i440FX + PIIX、1996）、BIOS 1.9.3-20161025_171302-gandalf 04/01/2014」、カーネル3.16.0-4-amd64）
ハイパーバイザーは、Debianテスト（現在、Debianの4.7.0-1-amd64; qemu 1：2.7 + dfsg-3）で実行されているlibvirt / KVMです。
ハードウェアは、スクラブが有効になっているECC RAMを備えたSupermicro H8SGL-F上のOpteron 6344 です。

ホストにNMIまたはEDACエラー/警告メッセージが表示されません。

ゲストでこれらのNMIメッセージの原因は何ですか？心配することはありますか？

（不明な理由20で受信したNMIに関連している可能性があります—奇妙な省電力モードが有効になっていますか？それはベアメタルのようです）。

— デロベルト
ソース

VMのカーネルに渡すのに役立つのだろうかnoapic apci=off

— Rui F Ribeiro

@RuiFRibeiroさて、現在、VMは（明らかな）問題なく動作しています。これは本番環境にあるため、再起動してランダムなカーネルオプションを試してみるのはやめた方がいいでしょう。（彼らはしている頻繁に-it'd確認するためにしばらく時間がかかるように、それはないですが、プラス）それは問題をデバッグするために、カーネルdevのを手助けした場合など、別の話だろう

— derobert

私はしばらくの間、同じ問題を追跡することを試みてきました。役立つ可能性があるデータポイントには、ホストカーネルバージョン、qemuバージョン、VMがBIOSを使用するかUEFIブートを使用するか、VMがi440fxまたはq35を使用するかどうかがあります。

— マイケルハンプトン

@MichaelHamptonが質問に追加された詳細をリクエストしました。

— derobert 2016

私は同じ問題を抱えています、ここに詳細があります（実際には非常によく似ています）：VMは、Debian jessie（3.16.0-4-amd64）とBIOS 1.7.5-20140531_083030-gandalf（04/01/2014）です。ハイパーバイザーは、Debian jessie上のlibvirt / KVMですが、バックポートされたカーネル（4.7.0-0.bpo.1-amd64）を備えています。ハイパーバイザーハードウェアは2つのOpteron 6272で、ECC RAM（マザーボードは現在不明ですが、おそらく何らかの種類のSupermicro）を備えています。これらの詳細がデロバートのものと非常に似ていることを考えると、私もこの問題に遭遇したことはそれほど驚くことではありませんが、うまくいけばそれらが役立つでしょう。

— jvperrin 16

回答:

私は同様の設定を使用して同じ問題がありました：

AMD CPU（Intel CPUでも同じ問題が報告されていますが、CPUパススルーを有効にしても、Intel CPUで実行しているハイパーバイザーにはこの問題はありません）。
ハイパーバイザーとゲスト上のDebian、カーネル4.x（私の場合は両方とも4.9.0-4-amd64）。

私の解決策は、ゲストVMを切り替えて、CPUパススルーではなくQEMUエミュレートされたCPUを使用することでした。これには<cpu mode='host-passthrough'/>、ゲスト定義ファイルから行を削除する必要がありました。

更新：私はさらに調査を行い、厄介な要素は要素の下にありましたclock：

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

本当の解決策は、3つの<timer>要素を削除する<cpu mode='host-passthrough'/>ことでした。その後、再び有効にすることができます。

完全を期すために、リンクされた質問に同様の回答を追加しました。

— mjturner
ソース

これらの3つの要素はデフォルト値であり、無効にすると何も実行されず、保存時に再度追加されます。

— Simon Richter

問題は、End of Interruptが適切に伝達されていないことです。

libvirtの場合、eoi有効になっていることを確認してください：

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

次のように変換されるKVMのコマンドライン

-cpu …,+kvm_pv_eoi

これは-M q35、ホストcpuパススルーとデフォルトの構成でうまくいくようです（RTC割り込みがキューに入れられ、PIT割り込みがドロップされ、HPETが利用できません）。

— サイモン・リヒター
ソース

私は上の同じ問題があったDebian 9とQemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5)。
ビデオカードモデルをからvirtioに置き換えることで解決しましたcirrus（または、qemuマニュアルページの別のモデルを使用してみてください）。

— オレグ・ゴロバノフ
ソース