Re: in-kernel interrupt controller steering

[Paolo Bonzini <pbonzini@redhat.com>]

> > Alex, would the PPC patches let you run with in-kernel "LAPICs"
> > and userspace "IOAPICs"?  If so, the new model would not be a
> > problem with QEMU at all.
> 
> The split on PPC isn't that clean. The MPIC doesn't split it at all
> for example. There we only have an "IOAPIC" without a "LAPIC". So
> setting the irqchip type to MPIC would be a nop.
> 
> For XICS, we would have something similar to a LAPIC. We would
> however have to communicate with that piece to tell it that
> interrupts are pending or not. I suppose this might be doable
> through the ONE_REG interface that Paul implemented, but I'm not
> sure.

Paul, can you confirm?

> I don't really think doing such a split makes sense though :).
> 
> > The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
> > KVM_CREATE_IRQCHIP_ARGS) forced you to later call
> > KVM_CREATE_DEVICE.
> 
> Ah, I see. I don't see why it would. The fact that there is a "LAPIC"
> doesn't mean that the per-vcpu SET_INTERRUPT ioctl stops working. So
> if SET_IRQCHIP_TYPE(!none) breaks user-space interrupt controller
> emulation I would consider that a bug.

If there's agreement that KVM_SET_IRQCHIP_TYPE doesn't force
subsequent KVM_CREATE_DEVICE calls (for CPU interrupt controllers
that's because they're controlled via ONE_REG and not DEVICE_ATTR),
I think we're fine.

Paolo