On 06.03.2013, at 14:56, Gleb Natapov wrote: > On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote: >> >> On 06.03.2013, at 14:14, Gleb Natapov wrote: >> >>> On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote: >>>>> 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. >> >> So SET_INTERRUPT on a vcpu triggers a line on the LAPIC emulation in that vcpu? For us it directly controls the CPU interrupt pin. >> > No SET_INTERRUPT on a vcpu tells vcpu to which vector in IDT it needs to > jump immediately. LAPIC is really part of a cpu and we cut it and put into > userspace, so interface between userspace LAPIC emulation is really low > level and has to be synchronous. X86 has two interrupt lines NMI and INTR > and we do not have interface to trigger the later. KVM_IRQ_LINE works on > GSI lines which do not go into CPU directly. They go either via PIC (which > triggers INTR or APIC LINT0) or via IOAPIC which on real HW communicates > with APICs via bus, but in our emulation just calls APICs directly. Great :). It's similar for us. SET_INTERRUPT directly asserts the INTR line of the vcpu. There is nothing like an IDT on PPC, so external interrupts simply arrive at a specific vector. That vector can differ for critical or NMI interrupts IIRC, but I'm not sure we implement that right now. If so, it'd be a different line for SET_INTERRUPT. So in a way, it's the same. And SET_INTERRUPT should work regardless of whether a LAPIC is used or not really. At least it would for us :). KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's fine. That ioctl should get an ioapic device handle to work on. Whether we call the IOAPIC PINs GSIs or something different is really just a naming question. I'd probably call it IRQ number :). But it's the same idea. The "IOAPIC" would then talk to to in-kernel "LAPIC" style bits (or in case of the MPIC just integrate them inside of itself). That's why by the time we create an "IOAPIC", the "LAPIC"s in the system have to be populated. So again, I'm failing to see where we think differently :). Alex -- 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
