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_q...@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(+)
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;
}
}
--
1.7.10.2.484.gcd07cc5
