From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54343 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OY266-00069x-An for qemu-devel@nongnu.org; Sun, 11 Jul 2010 15:21:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OY265-00061X-Aw for qemu-devel@nongnu.org; Sun, 11 Jul 2010 15:21:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43499) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OY265-00061O-26 for qemu-devel@nongnu.org; Sun, 11 Jul 2010 15:21:53 -0400 From: Alex Williamson In-Reply-To: <20100711185456.GA11048@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> Content-Type: text/plain; charset="UTF-8" Date: Sun, 11 Jul 2010 13:21:18 -0600 Message-ID: <1278876078.20397.79.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 21:54 +0300, Michael S. Tsirkin wrote: > On Sun, Jul 11, 2010 at 09:30:59PM +0300, Avi Kivity wrote: > > On 07/11/2010 09:26 PM, Alex Williamson wrote: > > >On Sun, 2010-07-11 at 21:14 +0300, Avi Kivity wrote: > > >>On 07/11/2010 09:09 PM, Alex Williamson wrote: > > >>>For device assignment, we need to know when the VM writes an end > > >>>of interrupt to the APIC, which allows us to de-assert the interrupt > > >>>line and clear the DisINTx bit. Add a new wrapper for ioapic > > >>>generated interrupts with a callback on eoi and create an interface > > >>>for drivers to be notified on eoi. > > >>> > > >>You aren't going to get this with kvm's in-kernel irqchip, so we need a > > >>new interface there. > > >Registering an eventfd for the eoi seems like a reasonable alternative. > > > > I'm worried about that racing (with what?) > > With device asserting the interrupt? > Need to make sure that all possible scenarious work well: > > device asserts interrupt > driver clears interrupt > device asserts interrupt > eoi > > device asserts interrupt > driver clears interrupt > eoi > device asserts interrupt > > etc > > Not that I see issues, these are things we need to check. I think those are all protected by host and qemu vfio drivers managing DisINTx. The way I understand it to work now is: device asserts interrupt interrupt lands in host vfio driver host vfio sets DisINTx on the device host vfio sends eventfd eventfd lands in qemu vfio, does a qemu_set_irq ... guest processes guest writes eoi to apic, lands back in qemu vfio driver qemu vfio deasserts qemu interrupt qemu vfio clears DisINTx So I don't think there's a race as long as ordering is sane for toggling DisINTx. Thanks, Alex