From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH] KVM: Add KVM_CAP_IRQ_ARCH capability Date: Thu, 14 Mar 2013 17:38:17 -0500 Message-ID: <1363300697.28440.18@snotra> References: <20130314222803.GJ9841@iris.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Alexander Graf , , To: Paul Mackerras Return-path: In-Reply-To: <20130314222803.GJ9841@iris.ozlabs.ibm.com> (from paulus@samba.org on Thu Mar 14 17:28:03 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 03/14/2013 05:28:03 PM, Paul Mackerras wrote: > On Thu, Mar 14, 2013 at 08:03:30PM +0100, Alexander Graf wrote: > > > > On 14.03.2013, at 19:35, Scott Wood wrote: > > > > > On 03/14/2013 01:33:30 PM, Alexander Graf wrote: > > >> We also want int pic_fd, no? > > > > > > Not sure we really need that on the vcpu. We'll need it on the > vm unless we add it as an arg to the vcpu cap enable. > > > > I don't think we need anything vm global for the cpu <-> PIC > connections. Also, if you want to deregister a CPU (hotplug remove), > you probably want to tell the PIC that the CPU has gone. > > I had kvm_arch_vcpu_free() calling a release function for the selected > PIC, which should be enough to let the PIC know the CPU has gone away, > I would think. Ah, sorry, I missed that somehow. > I agree we don't need anything vm global. The only vm ioctl which > needs to care about interrupt controllers is KVM_IRQ_LINE, and the > approach I take in my patchset is just to call all of the compiled-in > interrupt controllers until one of them takes it. KVM_IRQ_LINE is (eventually) supposed to go through the IRQ routing layer that determines which irqchip it goes to. Otherwise, how will we do things like generate MSIs through irqfd? At least, for those of us who haven't already mapped MSIs to normal interrupts inside QEMU via hcalls. :-) -Scott