On Mon, 10 Sep 2012, Matthew Ogilvie wrote: > > > 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 UNIX kernel. > > > > That is quite weird actually -- from my experience the spurious vector is > > never sent from a slave (quite understandably -- since the interrupt is > > gone and no other is pending, the master has no reason to select a slave > > to supply a vector and therefore supplies the spurious vector itself) and > > therefore a spurious IRQ7 is always issued regardless of whether the > > discarded request came from a slave or from the master. > > Keep in mind that this paragraph is describing QEMU's 8259 device > model behavior (and also KVM's), not real hardware. Reading the > unpatched code, the master clearly latches on to the momentary IRQ2, > does not cancel it when it is cleared again, and ultimately delivers > a spurious IRQ15. Well, it is your software model I am writing about. IIRC either (according to your previous understanding of the edge trigger mode) the master should latch IRQ2 and the slave IRQ14 both at a time until ackonwledged or both should (correctly) let it go. So, depending on the model implemented, you should see either IRQ14 or IRQ7 delivered, but never IRQ15. It does not make sense to me when you latch the cascade input in the master but no corresponding actual input in the slave, the chips are symmetrical. Anyway I infer you have corrected the model now and as a side effect no spurious IRQ15 is going to be delivered ever, right? Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
