From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFlJp-0002HC-UC for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:25:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFlJo-0002fU-0k for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:25:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFlJn-0002fJ-Lh for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:25:19 -0400 Message-ID: <4E9C109B.4070207@redhat.com> Date: Mon, 17 Oct 2011 13:25:15 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4E9C0C42.60201@redhat.com> <4E9C0F5C.8000602@siemens.com> In-Reply-To: <4E9C0F5C.8000602@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 12/45] msi: Introduce MSIRoutingCache List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Alex Williamson , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" On 10/17/2011 01:19 PM, Jan Kiszka wrote: > > IMO this needlessly leaks kvm information into core qemu. The cache > > should be completely hidden in kvm code. > > > > I think msi_deliver() can hide the use of the cache completely. For > > pre-registered events like kvm's irqfd, you can use something like > > > > qemu_irq qemu_msi_irq(MSIMessage msg) > > > > for non-kvm, it simply returns a qemu_irq that triggers a stl_phys(); > > for kvm, it allocates an irqfd and a permanent entry in the cache and > > returns a qemu_irq that triggers the irqfd. > > See my previously mail: you want to track the life-cycle of an MSI > source to avoid generating routes for identical sources. A messages is > not a source. Two identical messages can come from different sources. So > we need a separate data structure for that purpose. > Yes, I understand this now. Just to make sure I understand this completely: a hash table indexed by MSIMessage in kvm code would avoid this? You'd just allocate on demand when seeing a new MSIMessage and free on an LRU basis, avoiding pinned entries. I'm not advocating this (yet), just want to understand the tradeoffs. -- error compiling committee.c: too many arguments to function