Re: [STRAWMAN PATCH] KVM: PPC: Add ioctl to specify interrupt controller architecture to emulate

[Scott Wood <scottwood@freescale.com>]

On 03/08/2013 05:04:30 AM, Alexander Graf wrote:
> 
> 
> Am 08.03.2013 um 11:37 schrieb Paul Mackerras <paulus@samba.org>:
> 
> > 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