From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yunhong Jiang Subject: Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device Date: Tue, 5 Jan 2016 23:40:14 -0800 Message-ID: <20160106074014.GA15116@jnakajim-build> References: <1449166972-8894-1-git-send-email-yunhong.jiang@linux.intel.com> <5671A5DD.5060708@redhat.com> <1450293323.2674.37.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org To: Alex Williamson Return-path: Received: from mga04.intel.com ([192.55.52.120]:57267 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751341AbcAFHnn (ORCPT ); Wed, 6 Jan 2016 02:43:43 -0500 Content-Disposition: inline In-Reply-To: <1450293323.2674.37.camel@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Dec 16, 2015 at 12:15:23PM -0700, Alex Williamson wrote: > On Wed, 2015-12-16 at 18:56 +0100, Paolo Bonzini wrote: > > Alex, > >=20 > > can you take a look at the extension to the irq bypass interface in > > patch 2?=C2=A0=C2=A0I'm not sure I understand what is the case wher= e you have > > multiple consumers for the same token. >=20 > The consumers would be, for instance, Intel PI + the threaded handler > added in this series. =C2=A0These run independently, the PI bypass si= mply > makes the interrupt disappear from the host when it catches it, but i= f > the vCPU isn't running in the right place at the time of the interrup= t, > it gets delivered to the host, in which case the secondary consumer > implementing handle_irq() provides a lower latency injection than the Sorry for slow response. If the PI is delivered to the host because guest is not running, I thin= k it=20 will not trigger the secondary consumer. The reason is, with PI, the=20 interrupt will be delivered as the POSTED_INTR_VECTOR or=20 POSTED_INTR_WAKEUP_VECTOR. So for the PI consumer will not be invoked o= n run=20 time scenario. > eventfd path. =C2=A0If PI isn't supported, only this latter consumer = is > registered. >=20 > On the surface it seems like a reasonable solution, though having > multiple consumers implementing handle_irq() seems problematic. =C2=A0= Do we Yes, agree that has multiple consumers implementing handle_irq() seems = not=20 good. But I do think it can be helpful. A naive case is, a consumer can= be=20 created to log all the interrupt event, or to create a pipe for analysi= s. > get multiple injections if we call them all? =C2=A0Should we have som= e way As discussed above, currently I think we have only one consumer to=20 handle_irq(), so it should be ok? We can limit the framework to support= only=20 one consumer with handle_irq()? > to prioritize one handler versus another? =C2=A0Perhaps KVM should ha= ve a > single unified consumer that can provide that sort of logic, though w= e I'd think still different consumer for the PI and this fast_IRQ. Thanks --jyh > still need the srcu code added here to protect against registration a= nd > irq_handler() races. =C2=A0Thanks, >=20 > Alex >=20 > > On 03/12/2015 19:22, Yunhong Jiang wrote: > > > When assigning a VFIO device to a KVM guest with low latency > > > requirement, it=C2=A0=C2=A0 > > > is better to handle the interrupt in the hard interrupt context, = to > > > reduce=20 > > > the context switch to/from the IRQ thread. > > >=20 > > > Based on discussion on https://lkml.org/lkml/2015/10/26/764, the > > > VFIO msi=20 > > > interrupt is changed to use request_threaded_irq(). The primary > > > interrupt=20 > > > handler tries to set the guest interrupt atomically. If it fails = to > > > achieve=20 > > > it, a threaded interrupt handler will be invoked. > > >=20 > > > The irq_bypass manager is extended for this purpose. The KVM > > > eventfd will=20 > > > provide a irqbypass consumer to handle the interrupt at hard > > > interrupt=20 > > > context. The producer will invoke the consumer's handler then. > > >=20 > > > Yunhong Jiang (5): > > > =C2=A0 Extract the irqfd_wakeup_pollin/irqfd_wakeup_pollup > > > =C2=A0 Support runtime irq_bypass consumer > > > =C2=A0 Support threaded interrupt handling on VFIO > > > =C2=A0 Add the irq handling consumer > > > =C2=A0 Expose x86 kvm_arch_set_irq_inatomic() > > >=20 > > > =C2=A0arch/x86/kvm/Kconfig=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A01 + > > > =C2=A0drivers/vfio/pci/vfio_pci_intrs.c |=C2=A0=C2=A039 +++++++++= +-- > > > =C2=A0include/linux/irqbypass.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A08 +++ > > > =C2=A0include/linux/kvm_host.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A019 +++++- > > > =C2=A0include/linux/kvm_irqfd.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A01 + > > > =C2=A0virt/kvm/Kconfig=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2= =A0=C2=A03 + > > > =C2=A0virt/kvm/eventfd.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| 131 > > > ++++++++++++++++++++++++++------------ > > > =C2=A0virt/lib/irqbypass.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A082 ++++++++++= ++++++++------ > > > =C2=A08 files changed, 214 insertions(+), 70 deletions(-) > > >=20 >=20