From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Introduce generic interrupt injection for in-kernel irqchips Date: Mon, 23 Apr 2012 18:32:18 +0300 Message-ID: <4F957602.2090203@redhat.com> References: <4F734EB3.20500@siemens.com> <4F748AAD.2040103@siemens.com> <4F74B484.30607@siemens.com> <4F7B24EA.2070300@redhat.com> <4F847C35.9070105@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]:56907 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716Ab2DWPcY (ORCPT ); Mon, 23 Apr 2012 11:32:24 -0400 In-Reply-To: <4F847C35.9070105@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/10/2012 09:30 PM, Jan Kiszka wrote: > Currently, MSI messages can only be injected to in-kernel irqchips by > defining a corresponding IRQ route for each message. This is not only > unhandy if the MSI messages are generated "on the fly" by user space, > IRQ routes are a limited resource that user space has to manage > carefully. > > By providing a direct injection path, we can both avoid using up limited > resources and simplify the necessary steps for user land. This path is > provide in a way that allows for use with other interrupt sources as > well. Besides MSIs also external interrupt lines can be manipulated > through this interface, obsoleting KVM_IRQ_LINE_STATUS. > > Signed-off-by: Jan Kiszka > --- > > This picks up Avi's first suggestion as I still think it is the better > option to provide a direct MSI injection channel. My main objection to the previous patch was that it's not needed; qemu has to work with older kernels that have neither this nor the other patch. Given that, why do anything further? It won't be cleaner because the ugly path will remain for compatibility. Is there any concrete problem that this solves, that cannot be solved by a pure (but ugly) user space solution? wrt the patch itself, it seems fine. I have to agree that the single-purpose ioctl looks cleaner (but may be less suitable for a syscall based API). Just to add some confusion: is this future proof wrt iommu/interrupt remapping emulation? If you have a single iommu that intercepts all of the MSI space then there's no problem, but if there are multiple iommus, or if some devices are "in front of" the iommu, then we need to identify the source of the message as well. So we'd need an MBZ field for MSI injection, which can later be filled with the source ID. -- error compiling committee.c: too many arguments to function