From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCqky-0003dX-OB for qemu-devel@nongnu.org; Wed, 28 Mar 2012 07:09:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCqks-0006Mf-8a for qemu-devel@nongnu.org; Wed, 28 Mar 2012 07:09:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCqks-0006Mb-0L for qemu-devel@nongnu.org; Wed, 28 Mar 2012 07:09:30 -0400 Message-ID: <4F72F165.8020009@redhat.com> Date: Wed, 28 Mar 2012 13:09:25 +0200 From: Avi Kivity MIME-Version: 1.0 References: <865ef757142e5b9a670dfc9bcd8eb0ff7ab5d58b.1332371825.git.jan.kiszka@web.de> In-Reply-To: <865ef757142e5b9a670dfc9bcd8eb0ff7ab5d58b.1332371825.git.jan.kiszka@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 1/2] kvm: Introduce basic MSI support in-kernel irqchips List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Marcelo Tosatti , qemu-devel , kvm@vger.kernel.org, "Michael S. Tsirkin" On 03/22/2012 01:17 AM, Jan Kiszka wrote: > From: Jan Kiszka > > This patch basically adds kvm_irqchip_send_msi, a service for sending > arbitrary MSI messages to KVM's in-kernel irqchip models. > > As the current KVI API requires us to establish a static route from a s/KVI/KVM/ > pseudo GSI to the target MSI message and inject the MSI via toggling > that GSI, we need to play some tricks to make this unfortunately s/unfortunately/unfortunate/ > interface transparent. We create those routes on demand and keep them > in a hash table. Succeeding messages can then search for an existing > route in the table first and reuse it whenever possible. If we should > run out of limited GSIs, we simply flush the table and rebuild it as > messages are sent. > > This approach is rather simple and could be optimized further. However, > it is more efficient to enhance the KVM API so that we do not need this > clumsy dynamic routing over futures kernels. Two APIs are clumsier than one. wet the patch itself, suggest replacing the home grown hash with http://developer.gnome.org/glib/2.30/glib-Caches.html. -- error compiling committee.c: too many arguments to function