On Wed, Mar 28, 2012 at 01:09:25PM +0200, Avi Kivity wrote: > On 03/22/2012 01:17 AM, Jan Kiszka wrote: > > From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > > > > 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. I'd claim that the existing API is really not fit for what this patch wants to do, specifically support a huge number of MSI vectors. GSI routing was supposed to be mostly static. We do things like RCU slow path when they are changed, so routing changes during injection will be bad for real time guests. So either we want to support unlimited number of MSI vectors, in which case it makes sense to me to add kernel support to do this efficiently, or not in which case we don't need it in userspace either. No? > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
