| Message ID | 1355702189-6994-7-git-send-email-mmogilvi_qemu@miniinfo.net |
|---|---|
| State | New |
| Headers | show |
diff --git a/hw/i8259.c b/hw/i8259.c index 60c25ba..95587cd 100644 --- a/hw/i8259.c +++ b/hw/i8259.c @@ -157,6 +157,7 @@ static void pic_set_irq(void *opaque, int irq, int level) } s->last_irr |= mask; } else { + s->irr &= ~mask; s->last_irr &= ~mask; } }
Intel's definition of "edge triggered" means: "asserted with a low-to-high transition at the time an interrupt is registered and then kept high until the interrupt is served via one of the EOI mechanisms or goes away unhandled." So the only difference between edge triggered and level triggered is in the leading edge, with no difference in the trailing edge. This bug manifested itself when the guest was Microport UNIX System V/386 v2.1 (ca. 1987), because it would sometimes mask off IRQ14 in the slave IMR after it had already been asserted. The master would still try to deliver an interrupt even though IRQ2 had dropped again, resulting in a spurious interupt (IRQ15) and a panicked kernel. Output from a test program: ----------- Real hardware [Pentium 4]: cmdRead unmask IRR=4005 mask IRR=4001 sti unmask irq14 IRR=0001 DONE [I also see a final IRR=0000 occasionally. Probably just happened to ask it while the timer (IRQ0) line is low. It masks off most IRQ's, including timer.] ----------- Unpatched qemu: cmdRead unmask IRR=4015 mask IRR=4015 sti irq15 unmask IRR=4015 DONE [Presumably IRQ4 (0x10 - qemu's serial device model?) had a transient edge during initialization, but had been masked off even before I masked it off?] ----------- Patched qemu: cmdRead unmask IRR=4005 mask IRR=4001 sti unmask irq14 IRR=0001 DONE ----------- Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net> --- There is a risk that some other device models depend on the broken behavior. See my question about qemu_irq_pulse() in the cover letter. hw/i8259.c | 1 + 1 file changed, 1 insertion(+)