7

I recently had to work around a proprietary OS issue with the x86 PIC where the OS expected timer interrupts ONLY on CPU0. I enabled the IO-APIC to get around this and did CPU steering so the interrupts went only to CPU0. Problem solved.

I was told that our hardware is broken to do such a thing. i.e. raise timer interrupts on all CPUs when only a PIC is in use. The 'hardware' in question is QEMU/KVM.

Is QEMU/KVM at fault here ? Is the OS making an invalid assumption ?

My suspicion is that QEMU/KVM is perfectly correct in doing this and the OS should be able to handle timer interrupts on CPU != 0...

Kozmotronik
  • 2,080
  • 3
  • 10
  • 25
Goblinhack
  • 2,859
  • 1
  • 26
  • 26
  • Do you mean it interrupts every CPU at the same time, or that an interrupt can show up on any single one? It definitely should not go to all of them at once. I kind of remember something about always triggering the same CPU, but I think it would be reasonable to show up an any, especially if it is actually an IO-APIC emulating a PIC. – ughoavgfhw May 07 '14 at 02:04
  • What I saw was 99.99% of the time the timer would hit CPU0. After that it would randomly hit CPU1-7. My thought was that occasionally CPU0 would be busy and that would cause QEMU/KVM to choose another target for the interrupt. The bug in question only happened at load, so it seems likely. – Goblinhack May 07 '14 at 10:26
  • That definitely sounds like an IO-APIC. It sends to CPU 0 unless it has interrupts disabled at that instant. If you really want it to go to CPU 0, you could use the APICs to forward it, but it really is better to just configure the IO-APIC as you have. – ughoavgfhw May 07 '14 at 12:26
  • If I remember, I'll post an answer based on this later today, since we likely know the cause. – ughoavgfhw May 07 '14 at 12:45
  • In the case above there was no APIC enabled in QEMU/KVM. This was a PIC only solution. I did implement APIC/IO-APIC to fix the problem; but my question was really if this behaviour was correct for a PIC only box. PIC is not SMP aware, so it seems reasonable it would deliver interrupts to the next ready CPU. – Goblinhack May 07 '14 at 13:00

1 Answers1

4

I think it's true, the PIC ordinarily delivers interrupts only to CPU 0, including timer interrupts. Most OSes will not attempt SMP with PIC, since the CPU1-whatever cannot get or receive any interrupts (including some kind of timer interrupt for process scheduling); for example, Linux with "noapic" disables all but CPU0. I think this OS hit an odd corner case in qemu.

hwertz
  • 41
  • 2