On 29/10/2015 04:11, Alex Williamson wrote: > > The irqfd is already able to schedule a work item, because it runs with > > interrupts disabled, so I think we can always return IRQ_HANDLED. > > I'm confused by this. The problem with adding IRQF_NO_THREAD to our > current handler is that it hits the spinlock that can sleep in > eventfd_signal() and the waitqueue further down the stack before we get > to the irqfd. So if we split to a non-threaded handler vs a threaded > handler, where the non-threaded handler either returns IRQ_HANDLED or > IRQ_WAKE_THREAD to queue the threaded handler, there's only so much that > the non-threaded handler can do before we start running into the same > problem. You're right. I thought schedule_work used raw spinlocks (and then everything would be done in the inject callback), but I was wrong. Basically where irqfd_wakeup now does schedule_work, it would need to return IRQ_WAKE_THREAD. The threaded handler then can just do the eventfd_signal. Paolo > I think that means that the non-threaded handler needs to > return IRQ_WAKE_THREAD if we need to use the current eventfd_signal() > path, such as if the bypass path is not available. If we can get > through the bypass path and the KVM irqfd side is safe for the > non-threaded handler, inject succeeds and we return IRQ_HANDLED, right? > Thanks, -- 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
