On 16/12/2015 20:15, Alex Williamson wrote: > The consumers would be, for instance, Intel PI + the threaded handler > added in this series. These run independently, the PI bypass simply > makes the interrupt disappear from the host when it catches it, but if > the vCPU isn't running in the right place at the time of the interrupt, > it gets delivered to the host, in which case the secondary consumer > implementing handle_irq() provides a lower latency injection than the > eventfd path. If PI isn't supported, only this latter consumer is > registered. I would implement the two in a single consumer, knowing that only one of the two parts would effectively run. But because of the possibility of multiple consumers implementing handle_irq(), I am not sure if this is feasible. > On the surface it seems like a reasonable solution, though having > multiple consumers implementing handle_irq() seems problematic. Do we > get multiple injections if we call them all? Indeed. > Should we have some way > to prioritize one handler versus another? Perhaps KVM should have a > single unified consumer that can provide that sort of logic, though we > still need the srcu code added here to protect against registration and > irq_handler() races. Thanks, I'm happy to see that we have the same doubts. :) Paolo -- 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
