On 06/18/2012 05:18 PM, Alex Williamson wrote: >> >> I don't understand how this works. A level IRQ isn't de-asserted by the >> EOI, it's de-asserted by its source. >> >> Consider the following sequence: >> >> device guest >> >> event >> assert >> interrupt >> interrupt handler >> handle event >> clear ISR bit >> deassert >> event >> assert >> EOI >> >> What should happen is that the interrupt will be redelivered >> immmediately after the EOI, but that won't happen with your API since >> the EOI ack notifier will deassert the interrupt and nothing will >> re-assert it. > > A device that can de-assert it's own interrupt based on register/config > access probably isn't going to subscribe to this interface. Such a > device already has much greater visibility of it's service needs. In > the case where we have external devices, they'll reassert the interrupt, > which is part of this api that will need to be documented. > > Comparing this to real hardware, an eoi causes the ioapic to reassert > the interrupt if any of it's inputs are still active. Here we > preemptively de-assert our interrupt and require the user of the > interface to re-assert. Thanks, Okay. I guess this limits it assigned devices (which is fine, it just needs to be documented clearly). -- error compiling committee.c: too many arguments to function -- 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
