【发布时间】：2014-05-07 01:02:34
【问题描述】：
我最近不得不解决 x86 PIC 的专有操作系统问题，其中操作系统预期的计时器仅在 CPU0 上中断。我启用了 IO-APIC 来解决这个问题并进行 CPU 控制，因此中断只发送到 CPU0。问题解决了。
有人告诉我，我们的硬件坏了做这样的事情。即仅在使用 PIC 时在所有 CPU 上引发定时器中断。有问题的“硬件”是 QEMU/KVM。
QEMU/KVM 有问题吗？操作系统是否做出了无效假设？
我怀疑 QEMU/KVM 这样做是完全正确的，操作系统应该能够处理 CPU 上的定时器中断！= 0...
【问题讨论】：
-
你的意思是它同时中断每个CPU，还是任何一个CPU都可以出现中断？它绝对不应该同时传给他们所有人。我有点记得总是触发同一个 CPU，但我认为显示 any 是合理的，特别是如果它实际上是一个模拟 PIC 的 IO-APIC。
-
我看到的是 99.99% 的时间计时器会到达 CPU0。之后它会随机命中 CPU1-7。我的想法是偶尔 CPU0 会很忙，这会导致 QEMU/KVM 为中断选择另一个目标。有问题的错误只发生在加载时，所以看起来很有可能。
-
这听起来绝对像一个 IO-APIC。它发送到 CPU 0，除非它在那个时刻禁用了中断。如果你真的希望它去 CPU 0，你可以使用 APIC 来转发它，但最好只配置 IO-APIC。
-
如果我记得的话，我会在今天晚些时候发布一个基于此的答案，因为我们可能知道原因。
-
在上述情况下，QEMU/KVM 中没有启用 APIC。这是唯一的 PIC 解决方案。我确实实施了 APIC/IO-APIC 来解决这个问题；但我的问题是，这种行为对于仅限 PIC 的盒子是否正确。 PIC 不支持 SMP，因此它将中断传递给下一个准备好的 CPU 似乎是合理的。