From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHnOS-000144-Qe for qemu-devel@nongnu.org; Tue, 28 Jun 2016 03:25:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHnOP-0005cP-3J for qemu-devel@nongnu.org; Tue, 28 Jun 2016 03:25:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHnOO-0005b9-St for qemu-devel@nongnu.org; Tue, 28 Jun 2016 03:25:08 -0400 Date: Tue, 28 Jun 2016 15:25:02 +0800 From: Peter Xu Message-ID: <20160628072502.GE16629@pxdev.xzpeter.org> References: <1466495274-5011-1-git-send-email-peterx@redhat.com> <1466495274-5011-17-git-send-email-peterx@redhat.com> <576E3BEA.5010400@web.de> <20160625131854.GA16629@pxdev.xzpeter.org> <576EA0D0.3070602@web.de> <20160626014847.GB16629@pxdev.xzpeter.org> <576FD856.1020806@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <576FD856.1020806@web.de> Subject: Re: [Qemu-devel] [PATCH v10 16/26] intel_iommu: add support for split irqchip List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net, ehabkost@redhat.com, jasowang@redhat.com, marcel@redhat.com, mst@redhat.com, pbonzini@redhat.com, rkrcmar@redhat.com, alex.williamson@redhat.com, wexu@redhat.com, davidkiarie4@gmail.com, Valentine Sinitsyn On Sun, Jun 26, 2016 at 03:27:50PM +0200, Jan Kiszka wrote: > On 2016-06-26 03:48, Peter Xu wrote: > > On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote: > >> On 2016-06-25 15:18, Peter Xu wrote: > >>> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote: > > > > [...] > > > >>> I have a thought on how to implement the "sink" you have mentioned: > >>> > >>> First of all, in KVM, we provide a new KVM_IRQ_ROUTING_* type, maybe > >>> called: > >>> > >>> KVM_IRQ_ROUTING_EVENTFD > >> > >> Not really, because all sources are either using eventfds, which you can > >> also terminate in user space (already done for vhost and vfio in certain > >> scenarios - IIRC) or originate there anyway (IOAPIC). > > > > But how should we handle the cases when the interrupt path are all in > > kernel? > > There are none which we can't redirect (only full in-kernel irqchip > would have, but that's unsupported anyway). > > > > > For vhost, data should be transfered all inside kernel when split > > irqchip and irqfd are used: when vhost got data, it triggers irqfd to > > deliver the interrupt to KVM. Along the way, we should all in kernel. > > > > For vfio, we have vfio_msihandler() who handles the hardware IRQ and > > then triggers irqfd as well to KVM. Again, it seems all in kernel > > space, no chance to stop that as well. > > > > Please correct me if I was wrong. > > Look at what vhost is doing e.g.: when a virtqueue is masked, it > installs an event notifier that records incoming events in a pending > state field. When it's unmasked, the corresponding KVM irqfd is installed. You are right. Thanks for the explaination. -- peterx