From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M79mA-0003AA-3B for qemu-devel@nongnu.org; Thu, 21 May 2009 11:01:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M79m5-00038o-3p for qemu-devel@nongnu.org; Thu, 21 May 2009 11:01:41 -0400 Received: from [199.232.76.173] (port=51162 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M79m5-00038l-0m for qemu-devel@nongnu.org; Thu, 21 May 2009 11:01:37 -0400 Received: from mx20.gnu.org ([199.232.41.8]:64169) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M79m4-0001FB-9Z for qemu-devel@nongnu.org; Thu, 21 May 2009 11:01:36 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M79m3-000603-AL for qemu-devel@nongnu.org; Thu, 21 May 2009 11:01:35 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api Date: Thu, 21 May 2009 16:01:30 +0100 References: <20090520162130.GA22109@redhat.com> <200905211550.21217.paul@codesourcery.com> <4A156B41.4090608@redhat.com> In-Reply-To: <4A156B41.4090608@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905211601.33164.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Carsten Otte , kvm@vger.kernel.org, "Michael S. Tsirkin" , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Christian Borntraeger On Thursday 21 May 2009, Avi Kivity wrote: > 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. So presumably if a device triggers an APIC interrupt using a write that isn't one of the currently configured PCI devices, it all explodes horribly? Paul