From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ Date: Thu, 29 Oct 2015 10:45:44 +0100 Message-ID: <5631EAC8.1080805@redhat.com> References: <1445908801-14732-1-git-send-email-yunhong.jiang@linux.intel.com> <1445917034.8018.220.camel@redhat.com> <20151027063501.GA22054@jnakajim-build> <562F43F8.1040101@redhat.com> <20151027212648.GA22916@jnakajim-build> <56301A87.9030907@redhat.com> <1446048028.8018.387.camel@redhat.com> <5631003C.1050508@redhat.com> <1446088263.8018.435.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Yunhong Jiang , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marcelo Tosatti To: Alex Williamson Return-path: In-Reply-To: <1446088263.8018.435.camel@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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,