From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v3] KVM: Introduce direct MSI message injection for in-kernel irqchips Date: Fri, 13 Apr 2012 15:45:24 +0200 Message-ID: <4F882DF4.1090103@siemens.com> References: <4F734EB3.20500@siemens.com> <4F748AAD.2040103@siemens.com> <20120411221014.GA30150@amt.cnet> <4F86A029.2030509@siemens.com> <20120412223844.GA8712@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm , "Michael S. Tsirkin" , Eric Northup To: Marcelo Tosatti Return-path: Received: from goliath.siemens.de ([192.35.17.28]:30830 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752679Ab2DMNpa (ORCPT ); Fri, 13 Apr 2012 09:45:30 -0400 In-Reply-To: <20120412223844.GA8712@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-04-13 00:38, Marcelo Tosatti wrote: >>> Have you checked that direct MSI injection does not make use of >>> IRQ routing data structures, such as for acking? >> >> See kvm_set_msi: The routing structure is only read in the context of >> that function, no reference is kept. > > I was thinking more along the lines of inconsistent state > due to races. > > - set MSI for IOAPIC handled vector before kvm->irq_routing > is assigned. > - IOAPIC EOI for that vector. > - EOI handler expects kvm->irq_routing present. OK, starting to understand your worries. But isn't kvm->irq_routing always pointing to some traversable table after KVM_CREATE_IRQCHIP? If not, that race would have been exploitable before. > >>> irqchip_in_kernel(kvm) returns true before kvm->irq_routing is >>> actually in place. With kvm_set_irq there is no problem, but now >>> there is another path into injection. >>> >>> The real purpose of this is not entirely clear (and as Avi mentioned two >>> interfaces should be avoided if possible). >> >> See [1] for an implementation of one of Avi's proposals. > > Just now that i start to appreciate KVM_SIGNAL_MSI. > > "so we have a single ioctl for all interrupt handling. This allows > eventual removal of the line-oriented ioctls." > > So you move from one interface that handles both MSI/INTx, to _another_ > interface that handles both. KVM_SIGNAL_MSI with address/data is clean > and obvious. Well, I'm just looking for a MSI message injection mechanism. So I'm fine with both KVM_GENERAL_IRQ and KVM_SIGNAL_MSI. KVM_GENERAL_IRQ /may/ be helpful for kernel irqchips of upcoming arch if they need to provide IRQ injection paths that do not match well on the existing ones. However, it will surely take a long while until we can drop KVM_IRQ_LINE/KVM_IRQ_LINE_STATUS. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux