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