From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [STRAWMAN PATCH] KVM: PPC: Add ioctl to specify interrupt controller architecture to emulate Date: Wed, 13 Mar 2013 19:14:48 -0500 Message-ID: <1363220088.8945.18@snotra> References: <008F8D3C-7556-4034-BA44-A93593981249@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Paul Mackerras , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" , Gleb Natapov , Stuart Yoder To: Alexander Graf Return-path: In-Reply-To: <008F8D3C-7556-4034-BA44-A93593981249@suse.de> (from agraf@suse.de on Fri Mar 8 05:04:30 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 03/08/2013 05:04:30 AM, Alexander Graf wrote: > > > Am 08.03.2013 um 11:37 schrieb Paul Mackerras : > > > On Thu, Mar 07, 2013 at 03:00:52PM +0100, Alexander Graf wrote: > >> > >> Could you please (in a quick and drafty way) try and see if > setting the IRQ arch (using enable_cap) after the vcpu got created > would work for you? > >> > >> That enable_cap would then have to loop through all devices and > notify irq controllers that a new cpu got spawned. > >> All vcpu local payloads would have to get allocated and > initialized outside of vcpu_create too then. > > > > So, the first thing I noticed is that KVM_ENABLE_CAP is a vcpu > ioctl, > > not a vm ioctl. Apparently qemu calls it once for every vcpu when > it > > calls it on ppc targets. That means that it doesn't have to loop > > through all vcpus; it just needs to connect up the one it's called > > for, which simplifies things. > > That's the point, yes :). And if for some weird reason one vcpu isn't > connected to the interrupt controller (or to a different one), we can > model that too ;). > > > I'm coding it up now and porting my XICS emulation to the kvm device > > API proposed by Scott. It looks like it's going to be OK. > > Awesome! Scott is going to prototype whether using fds as tokens > makes sense. But even if we change it to an fd model, there should be > very little work to do to move xics to it too if it's already modeled > for create_device. It looks like the fd approach will be workable. Paul, do you want to post what you have in terms of the capability approach, so I can base an fd version of the device control patchset on it, or should I fd-ize the current patchset without it, and then rework mpic on top of the capability stuff once you've posted your device-control-using patchset? > > I have > > used the first argument (cap->args[0]) to specify which interrupt > > controller you want to connect the vcpu to. > > Ah, nice idea. So you basically make the vcpu connection explicit. > Perfect! Then just pass the interrupt controller pin id in > cap->args[1] so we don't need to guess which vcpu we're talking about > and all is well :). No implicit assumptions left in the kernel. Is the IRQ architecture now implicit based on what sort of irqchip you point at, or is there a separate capability for each IRQ architecture? The latter may make more sense -- you can test for specific architectures, provide architecture-specific arguments, some architectures may not require pointing at a device (e.g. the "LAPIC in kernel, IO-APIC in userspace" model), etc. -Scott