From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips Date: Wed, 04 Apr 2012 11:47:04 +0300 Message-ID: <4F7C0A88.2000902@redhat.com> References: <4F734EB3.20500@siemens.com> <4F748AAD.2040103@siemens.com> <4F74B484.30607@siemens.com> <4F7B24EA.2070300@redhat.com> <4F7B29B5.6060703@siemens.com> <4F7B2B4B.6080809@redhat.com> <4F7B3243.7050803@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , "Michael S. Tsirkin" , Eric Northup To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:18569 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753759Ab2DDIrL (ORCPT ); Wed, 4 Apr 2012 04:47:11 -0400 In-Reply-To: <4F7B3243.7050803@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/03/2012 08:24 PM, Jan Kiszka wrote: > > > >>> > >>> A performance note: delivering an interrupt needs to search all vcpus > >>> for an APIC ID match. The previous plan was to cache (or pre-calculate) > >>> this lookup in the irq routing table. Now it looks like we'll need a > >>> separate cache for this. > >> > >> As this is non-existent until today, we don't regress here. And it can > >> still be added on top later on, transparently. > > > > Yes, it's just a note, not an objection. The cache lookup will be > > slower than the gsi lookup (hash table vs. array) but still O(1) vs. the > > current O(n). > > If you are concerned about performance in this path, wouldn't a DMA > interface for MSI injection be counterproductive? Yes, it would. The lack of coalescing reporting support is also problematic. I just mentioned this idea as food for thought. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.