From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH v3 5/5] KVM: Allow host IRQ sharing for passed-through PCI 2.3 devices Date: Wed, 3 Nov 2010 19:42:59 +0200 Message-ID: <20101103174259.GD17089@redhat.com> References: <628f014fb1efb8e2208db03d13198ba301a3a34c.1288771873.git.jan.kiszka@web.de> <20101103084320.GF6772@redhat.com> <1288799867.3045.149.camel@x201> <4CD19B96.2080603@siemens.com> <4CD19D74.4080204@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Williamson , Avi Kivity , Marcelo Tosatti , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38962 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753106Ab0KCRnN (ORCPT ); Wed, 3 Nov 2010 13:43:13 -0400 Content-Disposition: inline In-Reply-To: <4CD19D74.4080204@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Nov 03, 2010 at 06:35:48PM +0100, Jan Kiszka wrote: > Am 03.11.2010 18:27, Jan Kiszka wrote: > > Am 03.11.2010 16:57, Alex Williamson wrote: > >> On Wed, 2010-11-03 at 10:43 +0200, Michael S. Tsirkin wrote: > >>> On Wed, Nov 03, 2010 at 09:11:16AM +0100, Jan Kiszka wrote: > >>>> From: Jan Kiszka > >>>> > >>>> PCI 2.3 allows to generically disable IRQ sources at device level. This > >>>> enables us to share IRQs of such devices between on the host side when > >>>> passing them to a guest. This feature is optional, user space has to > >>>> request it explicitly. > >>>> > >>>> Signed-off-by: Jan Kiszka > >>> > >>> > >>> I just realized something. > >>> With this patch, if guest ever looks at > >>> interrupt disable bit, it will go crazy as that bit goes on/off by > >>> itself. I guess we could have an ioctl to set/clear the bit on > >>> device, and have qemu call that on config write into command/status > >>> register. > >>> > >>> There's also something I don't completely unerstand with current code: > >>> how does interrupt sharing work? E.g. can assigned and emulated > >>> devices share an interrupt? > >> > >> I've been pondering this with VFIO too. There it seems to work, even > >> when I enable irqfd. The VFIO kernel/qemu driver needs to filter EOIs > >> based on whether the interrupt was actually asserted by the device, but > >> I think we're likely relying somewhat on interrupts being reasserted to > >> help us keep everything serviced. > > > > I don't think this filtering exists. The ack notifier that is fired on > > EOI matches the GSI, hitting anyone who is registered. > > > > I think the problem is that, while user space properly or's the input of > > all PCI devices on a IRQ line (e.g. in piix3_set_irq), kernel-side users > > apparently prefer to mess directly with the irqchip. Unless I'm missing > > something, that is long broken. > > No, it's actually or'ed in the kernel as well: kvm_irq_line_state. So, > any issue remaining? No issue. Assigned devices have a different source id, this is the trick I forgot about. Current VFIO patches go through userspace for level IRQs so it's simple, to make VFIO go directly through kernel we'll need to get a source id for each VFIO device, and associate it with eventfds somehow. > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux