From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api Date: Thu, 21 May 2009 16:12:31 +0300 Message-ID: <20090521131231.GH25309@redhat.com> References: <20090520162130.GA22109@redhat.com> <200905211329.41578.paul@codesourcery.com> <4A154B60.4080701@redhat.com> <200905211409.33325.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , qemu-devel@nongnu.org, Carsten Otte , kvm@vger.kernel.org, Rusty Russell , virtualization@lists.linux-foundation.org, Christian Borntraeger To: Paul Brook Return-path: Received: from mx2.redhat.com ([66.187.237.31]:47814 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753470AbZEUNQI (ORCPT ); Thu, 21 May 2009 09:16:08 -0400 Content-Disposition: inline In-Reply-To: <200905211409.33325.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, May 21, 2009 at 02:09:32PM +0100, Paul Brook wrote: > > > 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. So, is qemu_send_msi better than qemu_set_irq. > Either way, this is an implementation detail between pci.c and individual > devices. It has nothing to do with the APIC. > > Paul -- MST