From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752162AbbJ1RFJ (ORCPT ); Wed, 28 Oct 2015 13:05:09 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:34314 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750731AbbJ1RFH (ORCPT ); Wed, 28 Oct 2015 13:05:07 -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> Cc: Yunhong Jiang , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marcelo Tosatti From: Paolo Bonzini X-Enigmail-Draft-Status: N1110 Message-ID: <5631003C.1050508@redhat.com> Date: Wed, 28 Oct 2015 18:05:00 +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: <1446048028.8018.387.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 28/10/2015 17:00, Alex Williamson wrote: > > Alex, would it make sense to use the IRQ bypass infrastructure always, > > not just for VT-d, to do the MSI injection directly from the VFIO > > interrupt handler and bypass the eventfd? Basically this would add an > > RCU-protected list of consumers matching the token to struct > > irq_bypass_producer, and a > > > > int (*inject)(struct irq_bypass_consumer *); > > > > callback to struct irq_bypass_consumer. If any callback returns true, > > the eventfd is not signaled. > > Yeah, that might be a good idea, it's probably more plausible than > making the eventfd_signal() code friendly to call from hard interrupt > context. On the vfio side can we use request_threaded_irq() directly > for this? I don't know if that gives you a non-threaded IRQ with the real-time kernel... CCing Marcelo to get some insight. > Making the hard irq handler return IRQ_HANDLED if we can use > the irq bypass manager or IRQ_WAKE_THREAD if we need to use the eventfd. > I think we need some way to get back to irq thread context to use > eventfd_signal(). 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. There's another little complication. Right now, only x86 has kvm_set_msi_inatomic. We should merge kvm_set_msi_inatomic, kvm_set_irq_inatomic and kvm_arch_set_irq. Some cleanups are needed there; the flow between the functions is really badly structured because the API grew somewhat by accretion. I'll get to it next week or on the way back to Italy. > Would we ever not want to use the direct bypass > manager path if available? Thanks, I don't think so. KVM always registers itself as a consumer, even if there is no VT-d posted interrupts. add_producer simply returns -EINVAL then. Paolo