From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHmEd-0003fL-0i for qemu-devel@nongnu.org; Tue, 28 Jun 2016 02:11:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHmEY-0003xj-VA for qemu-devel@nongnu.org; Tue, 28 Jun 2016 02:10:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHmEY-0003xX-Po for qemu-devel@nongnu.org; Tue, 28 Jun 2016 02:10:54 -0400 Date: Tue, 28 Jun 2016 09:10:46 +0300 From: "Michael S. Tsirkin" Message-ID: <20160628061046.GA3381@redhat.com> 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=us-ascii 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: Peter Xu , qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net, ehabkost@redhat.com, jasowang@redhat.com, marcel@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). I agree but I kind of feel it's ok to work on this as a patch on top. Additionally, some kind of test would have to be written for these error cases, which is non-negligeable amount of worl. So I'm inlined to merge this patchset - I feel it'll help things make progress. Thoughts? Jan - if you agree it's a good idea, acks would be appreciated. > > > > 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. > > Jan > >