From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6seu-0005I8-Jf for qemu-devel@nongnu.org; Wed, 20 May 2009 16:45:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6seq-0005Hs-5z for qemu-devel@nongnu.org; Wed, 20 May 2009 16:45:04 -0400 Received: from [199.232.76.173] (port=41584 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6seq-0005Ho-3b for qemu-devel@nongnu.org; Wed, 20 May 2009 16:45:00 -0400 Received: from mail-bw0-f175.google.com ([209.85.218.175]:48931) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M6sep-00015o-Fw for qemu-devel@nongnu.org; Wed, 20 May 2009 16:44:59 -0400 Received: by bwz23 with SMTP id 23so607056bwz.34 for ; Wed, 20 May 2009 13:44:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090520203335.GC23518@redhat.com> References: <20090520162130.GA22109@redhat.com> <20090520173536.GA22935@redhat.com> <20090520182818.GC22935@redhat.com> <20090520200224.GA23500@redhat.com> <20090520201733.GA23518@redhat.com> <20090520203335.GC23518@redhat.com> Date: Wed, 20 May 2009 23:44:57 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Carsten Otte , kvm@vger.kernel.org, Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Christian Borntraeger , avi@redhat.com On 5/20/09, Michael S. Tsirkin wrote: > On Wed, May 20, 2009 at 11:26:42PM +0300, Blue Swirl wrote: > > On 5/20/09, Michael S. Tsirkin wrote: > > > On Wed, May 20, 2009 at 11:02:24PM +0300, Michael S. Tsirkin wrote: > > > > On Wed, May 20, 2009 at 09:38:58PM +0300, Blue Swirl wrote: > > > > > On 5/20/09, Michael S. Tsirkin wrote: > > > > > > On Wed, May 20, 2009 at 08:44:31PM +0300, Blue Swirl wrote: > > > > > > > On 5/20/09, Michael S. Tsirkin wrote: > > > > > > > > On Wed, May 20, 2009 at 08:21:01PM +0300, Blue Swirl wrote: > > > > > > > > > On 5/20/09, Michael S. Tsirkin wrote: > > > > > > > > > > define api for allocating/setting up msi-x irqs, and for updating them > > > > > > > > > > with msi-x vector information, supply implementation in ioapic. Please > > > > > > > > > > comment on this API: I intend to port my msi-x patch to work on top of > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Michael S. Tsirkin > > > > > > > > > > > > > > > > > > Sparc64 also uses packets ("mondos", not implemented yet) for > > > > > > > > > interrupt vector data, there the packet size is 8 * 64 bits. > > > > > > > > > I think we should aim for a more generic API that covers this case also. > > > > > > > > > > > > > > > > > > > > > > > > Are you sure this is a good idea? MSI is tied to PCI, and PCI only has > > > > > > > > MSI, not "mondos". What code would benefit from this abstraction? > > > > > > > > > > > > > > Sparc64 emulation, of course. I think also the API would be neater. > > > > > > > > > > > > > > > > > > Since "mondos" are not interrupts, why use irqs for them? > > > > > > > > > > I just said above that they are used for interrupt vector data. What > > > > > makes you think they are not interrupts? > > > > > > > > I'm sorry, I don't really know anything about sparc. > > > > All I am saying is that in PCI, interrupts never pass data, > > > > so qemu_set_irq as it is now, is a good API to send them. > > > > > > > > For the sparc feature you describe, you probably want to add > > > > a message data parameter to qemu_set_irq, but it's not > > > > really useful for MSI. > > > > > > > > > Just to clarify, the main difference is that with MSI/MSI-X > > > both data and address fields are mostly static, modifying them > > > involves ioapic and device updates which might be an expensive > > > operation (e.g. with kvm, needs an extra system call). > > > > > > So I don't think it makes sense to pass MSI-X data field > > > with each call to qemu_set_irq. > > > > No, but I think the Sparc situation is the same, the packet data is > > static for the interrupt source in question. > > > So, ok, we could add data update callback and then MSI and sparc > would do their thing there. I'm not convinced I like all this > play with untyped buffers, do you think it's helpful? > > If yes, maybe I'll try to code it up and see how does it look. Well, get/set_data could be limited to irq.c, ioapic.c could export something like get/set_msi_data. MSI callers should only use get/set_msi_data. Ditto for get/set_mondo_data.