From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: Coupling between KVM_IRQFD and KVM_SET_GSI_ROUTING? Date: Tue, 24 Jun 2014 12:40:39 +0200 Message-ID: <53A955A7.4060101@suse.de> References: <53A0290B.8040301@linaro.org> <53A85A37.9030103@suse.de> <20140624094713.GA24698@iris.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Auger , Antonios Motakis , "kvmarm@lists.cs.columbia.edu" , Marc Zyngier , "kvm@vger.kernel.org" , Christoffer Dall , Paolo Bonzini To: Paul Mackerras Return-path: Received: from cantor2.suse.de ([195.135.220.15]:39869 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753306AbaFXKkm (ORCPT ); Tue, 24 Jun 2014 06:40:42 -0400 In-Reply-To: <20140624094713.GA24698@iris.ozlabs.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 24.06.14 11:47, Paul Mackerras wrote: > On Mon, Jun 23, 2014 at 06:47:51PM +0200, Alexander Graf wrote: >> On 17.06.14 13:39, Eric Auger wrote: >>> Hello, >>> >>> I have a question related to KVM_IRQFD and KVM_SET_GSI_ROUTING ioctl >>> relationship. >>> >>> When reading the KVM API documentation I do not understand there is any >>> dependency between KVM_IRQFD and KVM_SET_GSI_ROUTING. According to the >>> text it seems only the gsi field is used and interpreted as the irqchip pin. >>> >>> However irqchip.c kvm_set_irq code relies on an existing and not dummy >>> routing table. >>> >>> My question is: does anyone agree on the fact the user-side must set a >>> consistent routing table using KVM_SET_GSI_ROUTING before using >>> KVM_IRQFD? The other alternative would have been to build a default >>> identity GSI routing table in the kernel (gsi = irqchip.pin). >> I untangled irqfd support from the x86 ioapic emulation a while back. When I >> looked at it, I didn't see any easy way to split it out from the routing >> too, so I kept that dependency in. >> >> If you look at the code, you will see that the irq routing entry is used as >> token for an irqfd. So every irqfd only knows its routing table entry, >> nothing else. > As far as I can see, the routing table entry is used for only two > things: to tell whether the interrupt is an MSI or LSI, and to pass to > kvm_set_msi. > > One way to tackle the problem would be to abstract out the routing > table lookup into a function in irqchip.c, rather than having it > open-coded in irqfd_update. Then, if you don't want to have the You could also create it along with the irqfd state struct. So instead of kzalloc(sizeof(*irqfd), GFP_KERNEL); we could do kzalloc(sizeof(*irqfd) + sizeof(struct kvm_kernel_irq_routing_entry), GFP_KERNEL); and point the routing entry to the inline irqfd one. We'd lose the ability to change any routings with that construct, but I think that's ok for irq controllers that are not configurable. Alternatively, we could also have a single routing entry that is a wildcard match, ranging from say LSI [x...y]. The irqfd structure would then need to carry a local payload to define an offset inside that wildcard routing entry. Alex