From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFlQ2-00019H-6v for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:31:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFlPy-0004go-8F for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:31:46 -0400 Received: from thoth.sbs.de ([192.35.17.2]:33612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFlPx-0004gT-Te for qemu-devel@nongnu.org; Mon, 17 Oct 2011 07:31:42 -0400 Message-ID: <4E9C121C.8050309@siemens.com> Date: Mon, 17 Oct 2011 13:31:40 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E9C0C42.60201@redhat.com> <4E9C0F5C.8000602@siemens.com> <4E9C109B.4070207@redhat.com> In-Reply-To: <4E9C109B.4070207@redhat.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: Avi Kivity Cc: Alex Williamson , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" On 2011-10-17 13:25, Avi Kivity wrote: > 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. Practically, that may work. I just wanted to avoid searching. And for static routes (irqfd, device assigment) you still need caches anyway, so I decided to use them consistently. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux