From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCv36-0006CX-8S for qemu-devel@nongnu.org; Wed, 28 Mar 2012 11:44:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCv2z-00023i-NB for qemu-devel@nongnu.org; Wed, 28 Mar 2012 11:44:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCv2z-00023U-G8 for qemu-devel@nongnu.org; Wed, 28 Mar 2012 11:44:29 -0400 Date: Wed, 28 Mar 2012 17:44:41 +0200 From: "Michael S. Tsirkin" Message-ID: <20120328154440.GC20176@redhat.com> References: <865ef757142e5b9a670dfc9bcd8eb0ff7ab5d58b.1332371825.git.jan.kiszka@web.de> <4F72F165.8020009@redhat.com> <4F72F6F5.5020202@siemens.com> <4F72F9A9.6000700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F72F9A9.6000700@redhat.com> 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: Avi Kivity Cc: Jan Kiszka , Marcelo Tosatti , qemu-devel , kvm@vger.kernel.org On Wed, Mar 28, 2012 at 01:44:41PM +0200, Avi Kivity wrote: > On 03/28/2012 01:33 PM, Jan Kiszka wrote: > > On 2012-03-28 13:09, Avi Kivity wrote: > > > 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/ > > > > Will fix these. > > Only needed if you end up reposting. > > > > > > >> 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. > > > > The current one is very clumsy for user-injected MSIs while the new one > > won't be. It will also be very simple it implement if you recall the > > patch. I think that is worth it. > > Don't see why. The clumsiness will be retained. The cpu doesn't care > how clumsy the API is, only the reader. It does care that the performance will be bad. GSIs were supposed by design to be static, so routing changes are slow. > > > > > > > > wet the patch itself, suggest replacing the home grown hash with > > > http://developer.gnome.org/glib/2.30/glib-Caches.html. > > > > Let's keep it simple :). We have no need for many of those features, and > > it would not be possible to implement the logic as compact as it is > > right now. > > Due to the callbacks? > > What if the code grows? > > -- > error compiling committee.c: too many arguments to function