x86 PIC，QEMU在所有CPU上引发中断是否正确？

我最近不得不解决x86 PIC的一个专有操作系统问题，在这个问题上，操作系统预期只会在CPU0上中断计时器。我启用了IO-APIC来解决这个问题，并进行了CPU控制，因此中断只会发生在CPU0上。问题解决了

有人告诉我，我们的硬件坏了，不能做这样的事。i、 e.只有PIC在使用时，所有CPU上的raise定时器中断。所讨论的“硬件”是QEMU/KVM

QEMU/KVM是否存在故障？操作系统是否做出了无效的假设

---

我怀疑QEMU/KVM这样做是完全正确的，操作系统应该能够处理CPU上的计时器中断！=0…

我认为这是真的，PIC通常只向CPU 0发送中断，包括计时器中断。大多数操作系统不会尝试使用PIC进行SMP，因为CPU1无法获取或接收任何中断（包括用于进程调度的某种计时器中断）；例如，带有“noapic”的Linux禁用除CPU0之外的所有功能。我认为这个操作系统在qemu中遇到了一个奇怪的情况。

你是说它同时中断了每个CPU，还是说一个中断可以出现在任何一个CPU上？绝对不应该一下子就把它全部发给他们。我记得一些关于总是触发同一个CPU的事情，但我认为显示any是合理的，特别是如果它实际上是一个模拟PIC的IO-APIC。我看到的是99.99%的时间计时器会命中CPU0。之后它会随机击中CPU1-7。我的想法是，有时CPU0会很忙，这会导致QEMU/KVM为中断选择另一个目标。问题中的bug只发生在加载时，所以看起来很有可能。这听起来绝对像IO-APIC。它发送到CPU 0，除非在该时刻禁用中断。如果你真的想让它转到CPU 0，你可以使用APIC转发它，但最好还是按照你的方式配置IO-APIC。如果我记得的话，我今天晚些时候会发布一个基于此的答案，因为我们可能知道原因。在上述情况下，QEMU/KVM中没有启用APIC。这是一个只有PIC的解决方案。我确实实现了APIC/IO-APIC来解决这个问题；但我的问题是，对于一个只有照片的盒子，这种行为是否正确。PIC不支持SMP，因此它将中断传送到下一个准备就绪的CPU似乎是合理的。