From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH 1/2] kvm: Introduce basic MSI support in-kernel irqchips Date: Wed, 28 Mar 2012 13:33:09 +0200 Message-ID: <4F72F6F5.5020202@siemens.com> References: <865ef757142e5b9a670dfc9bcd8eb0ff7ab5d58b.1332371825.git.jan.kiszka@web.de> <4F72F165.8020009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , qemu-devel , kvm@vger.kernel.org, "Michael S. Tsirkin" To: Avi Kivity Return-path: In-Reply-To: <4F72F165.8020009@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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. > >> 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. > > 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux