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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 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
--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux