From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips Date: Tue, 03 Apr 2012 19:24:19 +0200 Message-ID: <4F7B3243.7050803@siemens.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> 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: Avi Kivity Return-path: Received: from thoth.sbs.de ([192.35.17.2]:25847 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752644Ab2DCRYZ (ORCPT ); Tue, 3 Apr 2012 13:24:25 -0400 In-Reply-To: <4F7B2B4B.6080809@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-04-03 18:54, Avi Kivity wrote: > On 04/03/2012 07:47 PM, Jan Kiszka wrote: >>> >>> so we have a single ioctl for all interrupt handling. This allows >>> eventual removal of the line-oriented ioctls. >>> >>> The other alternative is to have a dma interface, similar to the kvm_run >>> mmio interface but with the kernel acting as destination. The advantage >>> here is that we can handle dma from a device to any kernel-emulated >>> device, not just the APIC MSI range. A downside is that we can't return >>> values related to interrupt coalescing. >> >> Due to lacking injection feedback, I'm in favor of option 1. Will have a >> look. > > I wonder if we can create a side channel for it. Lack of a kernel DMA > API is a hole in the current code, though we haven't been bitten by it > yet. An example is a guest that is swapping its own page tables; right > now the shadow mmu doesn't notice those writes (when the page tables are > swapped in) and will deliver incorrect results. Of course no guest does > that, so it doesn't happen in practice. > >>> >>> 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? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux