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 Standard 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。
硬件是Supermicro H8SGL-F上的Opteron 6344，具有ECC RAM（已启用清理）。

我在主机上看不到任何NMI或EDAC错误/警告消息。

知道是什么原因导致访客上的这些NMI消息吗？他们有什么需要担心的吗？

（可能与由于未知原因而收到的NMI有关20 —您是否启用了一种奇怪的省电模式？但这似乎是裸机）。

— 德罗伯特
source

我想知道传递给VM的内核是否会有所帮助noapic apci=off

— Rui F Ribeiro

@RuiFRibeiro好吧，当前VM正在正常运行，没有任何（明显）问题。它正在生产中，所以我不想四处重启以尝试使用随机内核选项。如果是要帮助内核开发人员调试问题等，情况将大为不同。（此外，这并不像他们经常使用-需要花点时间才能确定。）

— derobert

我已经尝试寻找相同的问题已有一段时间了。可能有用的一些数据点包括：主机内核版本，qemu版本，VM是否使用BIOS或UEFI引导，VM使用i440fx还是q35。

— 迈克尔·汉普顿

@MichaelHampton要求将详细信息添加到问题中。

— derobert

我遇到了同样的问题，以下是详细信息（实际上非常相似）：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）。系统管理程序硬件是两个Opteron 6272s，带有ECC RAM（主板目前未知，但可能是某种类型的Supermicro）。鉴于这些细节与derobert的细节非常相似，因此我也遇到这个问题并不令我感到惊讶，但希望它们会有所帮助。

— jvperrin

Answers:

使用类似的设置，我遇到了同样的问题：

AMD CPU（尽管我已经看到有关Intel CPU的相同问题的报告，但是即使启用了CPU直通，我在Intel CPU上运行的虚拟机管理程序都没有这个问题）。
Debian，hypervisor和guest虚拟机上的内核4.x（在我的情况下均为4.9.0-4-amd64）。

我的解决方案是将来宾VM切换为使用QEMU模拟的CPU，而不是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>

真正的解决方案是删除这三个<timer>元素，然后<cpu mode='host-passthrough'/>可以再次启用它们。

为了完整性，我对链接的问题添加了类似的答案。

— mjturner
source

这三个元素是默认值，禁用它们应该完全不执行任何操作，并在保存时重新添加它们。

— Simon Richter

问题似乎是中断结束通信不正确。

对于libvirt，请确保eoi已启用：

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

在KVM的命令行上转换为

-cpu …,+kvm_pv_eoi

这对于我们来说似乎很有效，-M q35否则，主机cpu直通和默认配置（RTC中断已排队，PIT中断已删除，HPET不可用）。

— 西蒙·里希特
source

我在Debian 9和遇到了同样的问题Qemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5)。
我决定它由更换的显卡型号virtio到cirrus（或者你可以尝试使用来自另一个模型qemu手册页）。

— 奥列格·戈洛瓦诺夫（Oleg Golovanov）
source