From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752296AbbJ2Jpz (ORCPT ); Thu, 29 Oct 2015 05:45:55 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:33940 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828AbbJ2Jpx (ORCPT ); Thu, 29 Oct 2015 05:45:53 -0400 Subject: Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ To: Alex Williamson 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> Cc: Yunhong Jiang , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marcelo Tosatti From: Paolo Bonzini X-Enigmail-Draft-Status: N1110 Message-ID: <5631EAC8.1080805@redhat.com> Date: Thu, 29 Oct 2015 10:45:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1446088263.8018.435.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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,