On Wed, Dec 16, 2015 at 10:55:12PM +0100, Paolo Bonzini wrote: > > > 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. So is it possible that we limit only one consumer with handle_irq(), as my previous response to Alex? We can extend it in future if we do need support multiple consumder implementing handle_irq()? Thanks --jyh > > > 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 linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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
