From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M79Rf-0003Np-ON for qemu-devel@nongnu.org; Thu, 21 May 2009 10:40:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M79Ra-0003IG-R6 for qemu-devel@nongnu.org; Thu, 21 May 2009 10:40:31 -0400 Received: from [199.232.76.173] (port=53368 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M79Ra-0003Hy-IS for qemu-devel@nongnu.org; Thu, 21 May 2009 10:40:26 -0400 Received: from mx2.redhat.com ([66.187.237.31]:35703) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M79Ra-0005EI-2I for qemu-devel@nongnu.org; Thu, 21 May 2009 10:40:26 -0400 Message-ID: <4A156739.6060207@redhat.com> Date: Thu, 21 May 2009 17:37:45 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api References: <20090520162130.GA22109@redhat.com> <200905211453.14691.paul@codesourcery.com> <4A155EC6.6070501@redhat.com> <200905211514.31059.paul@codesourcery.com> In-Reply-To: <200905211514.31059.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, "Michael S. Tsirkin" , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Christian Borntraeger Paul Brook wrote: > On Thursday 21 May 2009, Avi Kivity wrote: > >> Paul Brook wrote: >> >>>>> which is a trivial wrapper around stl_phys. >>>>> >>>> OK, but I'm adding another level of indirection in the middle, >>>> to allow us to tie in a kvm backend. >>>> >>> 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. -- error compiling committee.c: too many arguments to function