On Thu, Oct 29, 2015 at 10:45:44AM +0100, Paolo Bonzini wrote: > > > 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. > And with this change, we even don't need the module option anymore, we first try the primary handler, which is in hard irq context, and if failed, then threaded irq handler. Am I right? Paolo/Alex, do you want to work on the patch yourself? If not, I will be happy to try this method. Thanks --jyh > 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
