Il 06/03/2013 14:14, Gleb Natapov ha scritto: >>>> 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. >> > For x86 this is the case though. I do not see how it can't be. If > LAPIC is emulated in userspace SET_INTERRUPT is used to pass IRQ > vector that should be handled as a result of LAPIC emulation. SET_IRQCHIP_TYPE creates the LAPICs; it would indeed break userspace LAPIC emulation because the LAPICs would not cause userspace exits anymore. However, it need not mandate the usage of an in-kernel IOAPIC or PIC though. KVM_INTERRUPT, the docs say, "is only useful if in-kernel local APIC or equivalent is not used", but it is really only useful for if in-kernel *IOAPIC* is not used. The userspace IOAPIC can use it to inject the interrupts to the in-kernel LAPIC. So, it would be possible to create the IOAPIC or PIC separately with KVM_CREATE_DEVICE, and have the userspace devices inject the interrupts with KVM_IRQ_LINE_STATUS (PIC->IOAPIC) or KVM_INTERRUPT (IOAPIC->LAPIC). 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
