From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M781o-0004k8-A2 for qemu-devel@nongnu.org; Thu, 21 May 2009 09:09:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M781j-0004fE-Fn for qemu-devel@nongnu.org; Thu, 21 May 2009 09:09:44 -0400 Received: from [199.232.76.173] (port=36217 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M781j-0004ew-9j for qemu-devel@nongnu.org; Thu, 21 May 2009 09:09:39 -0400 Received: from mx20.gnu.org ([199.232.41.8]:55297) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M781i-0006Z4-Vn for qemu-devel@nongnu.org; Thu, 21 May 2009 09:09:39 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M781f-0005da-Rw for qemu-devel@nongnu.org; Thu, 21 May 2009 09:09:36 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api Date: Thu, 21 May 2009 14:09:32 +0100 References: <20090520162130.GA22109@redhat.com> <200905211329.41578.paul@codesourcery.com> <4A154B60.4080701@redhat.com> In-Reply-To: <4A154B60.4080701@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905211409.33325.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 > > A tight coupling between PCI devices and the APIC is just going to cause > > us problems later one. I'm going to come back to the fact that these are > > memory writes so once we get IOMMU support they will presumably be > > subject to remapping by that, just like any other memory access. > > I'm not suggesting the qemu_irq will extend all the way to the apic. > Think of it as connecting the device core with its interrupt unit. > > > Even ignoring that, qemu_irq isn't really the right interface. A MSI is a > > one- off event, not a level state. OTOH stl_phys is exactly the right > > interface. > > The qemu_irq callback should do an stl_phys(). The device is happy > since it's using the same API it uses for non-MSI. MSI provides multiple edge triggered interrupts, whereas traditional mode provides a single level triggered interrupt. My guess is most devices will want to treat these differently anyway. Either way, this is an implementation detail between pci.c and individual devices. It has nothing to do with the APIC. Paul