Re: [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux