On Wed, Mar 13, 2013 at 07:14:48PM -0500, Scott Wood wrote: > On 03/08/2013 05:04:30 AM, Alexander Graf wrote: > > > > > >Am 08.03.2013 um 11:37 schrieb Paul Mackerras <paulus@xxxxxxxxx>: > > > >> 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 a complete patchset based on your "kvm: add device control API" patch, tested and ready to go. :) I just posted the first patch of that series, the one that adds the KVM_CAP_IRQ_ARCH capability. If you're going to change the device API then I'll hold off posting the rest of the series for now. > >> 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. The way I have done it, there is one capability, and args[0] is a token for the IRQ architecture (not a device ID). I arbitrarily assigned 0x58494353 for KVM_CAP_IRQ_XICS as the args[0] value to indicate XICS. I think it would be better if we don't have to get a new capability number assigned every time we want to add a new type of interrupt controller. Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
