Re: [PATCH 3/9] KVM: PPC: Book3S: Add kernel emulation for the XICS interrupt controller

[Paul Mackerras <paulus@samba.org>]

On Mon, Feb 18, 2013 at 04:43:27PM -0600, Scott Wood wrote:
> On 02/15/2013 10:51:16 PM, Paul Mackerras wrote:
> >The KVM_CREATE_IRQCHIP_ARGS ioctl says that you want emulation of a
> >specific interrupt controller architecture connected to the vcpus'
> >external interrupt inputs.  In that sense it's explicit, compared to a
> >generic "create device" ioctl that could be for any device.
> 
> Hooking up to the CPU's interrupt lines is implicit in creating an
> MPIC (and I'm fine with changing that), not in creating any device.
> I don't see how it's worse than being implicit in calling
> KVM_CREATE_IRQCHIP_ARGS (which doesn't allow for cascaded irqchips).

First, KVM_CREATE_IRQCHIP_ARGS specifies the overall architecture of
the interrupt control subsystem, so yes it does allow for cascaded
controllers.

Secondly, the difference is that if you see a KVM_CREATE_IRQCHIP_ARGS
call, you know that the vcpus' interrupt inputs will be driven by
kernel code.  If you see a KVM_CREATE_DEVICE call, you don't know
that; they might be, or they might not be.

> >You're doing a round trip to userspace for every MPIC register access
> >by the guest?  Seriously?
> 
> No.  Accesses by the guest get handled in the kernel.  Accesses in
> QEMU, including MSIs generated by virtio, get forwarded to the
> kernel.

OK, I missed the path where that gets done, then.

> >It would be the current task priority.  I assume MPIC maintains a
> >16-bit map of the interrupt priorities in service, so that would need
> >to be added.
> 
> We don't maintain such a map in the emulation code.  We have a

Oh, so how do you handle EOI of nested interrupts?  How do you know
what to reset the CPU priority to in that case?

> per-CPU bitmap of the actual interrupt sources pending/active, which
> is another attribute that would need to be added in order to support
> migration on MPIC.

Not really, that can be recomputed from the sources easily enough.

Paul.