On 08/08/2012 03:49 AM, David Gibson wrote: >> > We never have irqchip in kernel (because we haven't written that yet) >> > but we still sleep in-kernel for CEDE. I haven't spotted any problem >> > with that, but now I'm wondering if there is one, since x86 don't do >> > it in what seems like the analogous situation. >> > >> > It's possible this works because our decrementer (timer) interrupts >> > are different at the core level from external interrupts coming from >> > the PIC, and *are* handled in kernel, but I haven't actually followed >> > the logic to work out if this is the case. >> > >> >> Meaning the normal state of things is to sleep in >> >> the kernel (whether or not you have an emulated interrupt controller in >> >> the kernel -- the term irqchip in kernel is overloaded for x86). >> > >> > Uh.. overloaded in what way. >> >> On x86, irqchip-in-kernel means that the local APICs, the IOAPIC, and >> the two PICs are emulated in the kernel. Now the IOAPIC and the PICs >> correspond to non-x86 interrupt controllers, but the local APIC is more >> tightly coupled to the core. Interrupt acceptance by the core is an >> operation that involved synchronous communication with the local APIC: >> the APIC presents the interrupt, the core accepts it based on the value >> of the interrupt enable flag and possible a register (CR8), then the >> APIC updates the ISR and IRR. >> >> The upshot is that if the local APIC is in userspace, interrupts must be >> synchronous with vcpu exection, so that KVM_INTERRUPT is a vcpu ioctl >> and HLT is emulated in userspace (so that local APIC emulation can check >> if an interrupt wakes it up or not). > > Sorry, still not 100% getting it. When the vcpu is actually running > code, that synchronous communication must still be accomplished via > the KVM_INTERRUPT ioctl, yes? So what makes HLT different, that the > communication can't be accomplished in that case. No, you're correct. HLT could have been emulated in userspace, it just wasn't. The correct statement is that HLT was arbitrarily chosen to be emulated in userspace with the synchronous model, but the asynchronous model forced it into the kernel. -- error compiling committee.c: too many arguments to function -- 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
