From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M7BVc-0002cO-6B for qemu-devel@nongnu.org; Thu, 21 May 2009 12:52:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M7BVX-0002Y3-DA for qemu-devel@nongnu.org; Thu, 21 May 2009 12:52:43 -0400 Received: from [199.232.76.173] (port=59769 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M7BVX-0002Xu-9X for qemu-devel@nongnu.org; Thu, 21 May 2009 12:52:39 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58793) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M7BVW-0006TN-R2 for qemu-devel@nongnu.org; Thu, 21 May 2009 12:52:39 -0400 Date: Thu, 21 May 2009 19:49:34 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api Message-ID: <20090521164934.GB6474@redhat.com> References: <20090520162130.GA22109@redhat.com> <200905211514.31059.paul@codesourcery.com> <4A156739.6060207@redhat.com> <200905211550.21217.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905211550.21217.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Carsten Otte , kvm@vger.kernel.org, Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Christian Borntraeger , Avi Kivity On Thu, May 21, 2009 at 03:50:18PM +0100, Paul Brook wrote: > > >>> kvm has no business messing with the PCI device code. > > >> > > >> kvm has a fast path for irq injection. If qemu wants to support it we > > >> need some abstraction here. > > > > > > Fast path from where to where? Having the PCI layer bypass/re-implement > > > the APIC and inject the interrupt directly into the cpu core sounds a > > > particularly bad idea. > > > > kvm implements the APIC in the host kernel (qemu upstream doesn't > > support this yet). The fast path is wired to the in-kernel APIC, not > > the cpu core directly. > > > > The idea is to wire it to UIO for device assignment, to a virtio-device > > implemented in the kernel, and to qemu. > > I still don't see why you're trying to bypass straight from the pci layer to > the apic. Why can't you just pass the apic MMIO writes to the kernel? You've > presumably got to update the apic state anyway. > > Paul As far as I can tell, at least on Intel, MSI interrupts are not MMIO writes. They are PCI memory writes to a hard-coded address range that are passed to APIC. I don't think MMIO writes can triger MSI, or at least this does not seem to be documented. -- MST