On 14.03.2013, at 01:14, Scott Wood wrote: > On 03/08/2013 05:04:30 AM, Alexander Graf wrote: >> Am 08.03.2013 um 11:37 schrieb Paul Mackerras <pau...@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.
Very nice :). > 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. I tend to be quite indifferent whether we should make it implicit or explicit. But so far, explicit usually ended up more flexible and a better interface. So yes, let's go with different CAPs for different interrupt controllers. However, let's make sure the parameters stay compatible for now. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
