From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M79ho-000148-4B for qemu-devel@nongnu.org; Thu, 21 May 2009 10:57:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M79hj-00012r-O5 for qemu-devel@nongnu.org; Thu, 21 May 2009 10:57:11 -0400 Received: from [199.232.76.173] (port=48419 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M79hj-00012o-Fr for qemu-devel@nongnu.org; Thu, 21 May 2009 10:57:07 -0400 Received: from mx20.gnu.org ([199.232.41.8]:63818) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M79hj-0008C4-3S for qemu-devel@nongnu.org; Thu, 21 May 2009 10:57:07 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M79hi-0005gu-62 for qemu-devel@nongnu.org; Thu, 21 May 2009 10:57:06 -0400 Message-ID: <4A156B41.4090608@redhat.com> Date: Thu, 21 May 2009 17:54:57 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api References: <20090520162130.GA22109@redhat.com> <200905211514.31059.paul@codesourcery.com> <4A156739.6060207@redhat.com> <200905211550.21217.paul@codesourcery.com> In-Reply-To: <200905211550.21217.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: >> 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. > The fast path is an eventfd so that we don't have to teach all the clients about the details of MSI. Userspace programs the MSI details into kvm and hands the client an eventfd. All the client has to do is bang on the eventfd for the interrupt to be queued. The eventfd provides event coalescing and is equally useful from the kernel and userspace, and can be used with targets other than kvm. -- error compiling committee.c: too many arguments to function