On Wed, Aug 08, 2012 at 11:58:58AM +0300, Avi Kivity wrote: > 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. Aha! Ok, understood. Uh, assuming you meant kernelspace, not userspace in the first line there, anyway. Ok, so I am now reassured that our current handling of CEDE in kernelspace does not cause problems. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- 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
