On Mon, Feb 04, 2013 at 12:43:45PM -0200, Marcelo Tosatti wrote: > > > Any example how software relies on such two-interrupts-queued-in-IRR/ISR behaviour? > > Don't know about guests, but KVM relies on it to detect interrupt > > coalescing. So if interrupt is set in IRR but not in PIR interrupt will > > not be reported as coalesced, but it will be coalesced during PIR->IRR > > merge. > > Yes, so: > > 1. IRR=1, ISR=0, PIR=0. Event: set_irq, coalesced=no. > 2. IRR=0, ISR=1, PIR=0. Event: IRR->ISR transfer. > 3. vcpu outside of guest mode. > 4. IRR=1, ISR=1, PIR=0. Event: set_irq, coalesced=no. > 5. vcpu enters guest mode. > 6. IRR=1, ISR=1, PIR=1. Event: set_irq, coalesced=no. > 7. HW transfers PIR into IRR. > > set_irq return value at 7 is incorrect, interrupt event was _not_ > queued. Not sure I understand the flow of events in your description correctly. As I understand it at 4 set_irq() will return incorrect result. Basically when PIR is set to 1 while IRR has 1 for the vector the value of set_irq() will be incorrect. Frankly I do not see how it can be fixed without any race with present HW PIR design. -- Gleb. -- 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
