* Gleb Natapov <gleb@xxxxxxxxxx> [2012-01-17 14:51:26]: > On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote: > > * Gleb Natapov <gleb@xxxxxxxxxx> [2012-01-17 11:14:13]: > > > > > > The problem case I was thinking of was when guest VCPU would have issued > > > > HLT with interrupts disabled. I guess one option is to inject an NMI, > > > > and have the guest kernel NMI handler recognize this and make > > > > adjustments such that the vcpu avoids going back to HLT instruction. > > > > > > > Just kick vcpu out of a guest mode and adjust rip to point after HLT on > > > next re-entry. Don't forget to call vmx_clear_hlt(). > > > > Looks bit hackish to me compared to having another hypercall to yield! > > > Do not see anything hackish about it. But what you described above (the > part I replied to) is not another hypercall, but yet another NMI source > and special handling in a guest. True, which I didn't exactly like and hence was suggesting we use another hypercall to let spinning vcpu sleep. > So what hypercall do you mean? The hypercall is described below: > > > > Having another hypercall to do yield/sleep (rather than effecting that > > > > via HLT) seems like an alternate clean solution here .. and was implemented in an earlier version of this patch (v2) as KVM_HC_WAIT_FOR_KICK hypercall: https://lkml.org/lkml/2011/10/23/211 Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to hypervisor vs assuming that because of a trapped HLT instruction (which will anyway won't work when yield_on_hlt=0). - vatsa _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
