From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55266 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OY4YT-0005nL-Ky for qemu-devel@nongnu.org; Sun, 11 Jul 2010 17:59:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OY4YS-0005xi-Ds for qemu-devel@nongnu.org; Sun, 11 Jul 2010 17:59:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59114) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OY4YS-0005xa-5X for qemu-devel@nongnu.org; Sun, 11 Jul 2010 17:59:20 -0400 From: Alex Williamson In-Reply-To: <20100711201246.GA12544@redhat.com> References: <20100711180910.20121.93313.stgit@localhost6.localdomain6> <20100711180936.20121.35376.stgit@localhost6.localdomain6> <4C3A09F3.8010304@redhat.com> <1278872784.20397.18.camel@x201> <4C3A0DE3.8010806@redhat.com> <20100711185456.GA11048@redhat.com> <1278876078.20397.79.camel@x201> <20100711192330.GA11491@redhat.com> <1278878614.20397.128.camel@x201> <20100711201246.GA12544@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 11 Jul 2010 15:59:15 -0600 Message-ID: <1278885555.20397.181.camel@x201> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC PATCH 4/5] APIC/IOAPIC EOI callback List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: chrisw@redhat.com, pugs@cisco.com, Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On Sun, 2010-07-11 at 23:12 +0300, Michael S. Tsirkin wrote: > On Sun, Jul 11, 2010 at 02:03:34PM -0600, Alex Williamson wrote: > > > What about threaded interrupts? > > Just to make the point, imagine a nested virt situation > which uses current kvm device assignment in guest. > Look at the interrupt handler we have there. Is the problem you're worried about this: guest masks qemu ioapic rte device interrupt host vfio DisINTx+ qemu vfio calls qemu_set_irq ... In that case, the qemu ioapic irr bit is only toggled by qemu_set_irq for level triggered interrupts, so the interrupt will be asserted in the guest when it gets unmasked and we'll get the eoi. I can't figure out where your other scenario can leave the DisINTx+: device asserts interrupt a) DisINTx+ via host vfio guest disables interrupt b) DisINTx+ via guest, already set eoi c) DisINTx- via qemu vfio driver clears interrupt guest enables interrupt d) DisINTx- via guest device asserts interrupt So between c) & d) we're potentially getting more interrupts than we want, but I can't see anywhere that we drop DisINTx. If you have a scenario, let me know. Thanks, Alex