On 10/25/2012 06:41 PM, Jan Kiszka wrote: > On 2012-10-25 18:23, Avi Kivity wrote: >> On 10/25/2012 03:34 PM, Jan Kiszka wrote: >> >>>>> Second, it clearly shows that we need to address lock-less IRQ delivery. >>>>> Almost nothing is won if we have to take the global lock again to push >>>>> an IRQ event to the guest. I'm repeating myself, but the problem to be >>>>> solved here is almost identical to fast IRQ delivery for assigned >>>>> devices (which we only address pretty ad-hoc for PCI so far). >>>>> >>>> Interesting, could you show me more detail about it, so I can google... >>> >>> No need to look that far, just grep for pci_device_route_intx_to_irq, >>> pci_device_set_intx_routing_notifier and related functions in the code. >> >> We can address it in the same way the memory core supports concurrency, >> by copying dispatch information into rcu or lock protected data structures. >> >> But I really hope we can avoid doing it now. > > I doubt so as the alternative is taking the BQL while (still) holding > the device lock.
Sorry, doesn't parse. > But that creates ABBA risks. -- error compiling committee.c: too many arguments to function
