On Tue, Jan 17, 2012 at 06:41:03PM +0530, Srivatsa Vaddagiri wrote: > * 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. > Ah, sorry. Missed that. > > 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). > The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the entire time slice no mater what. I do not think disabling yield on HLT is even make sense in CPU oversubscribe scenario. Now if you'll call KVM_HC_WAIT_FOR_KICK instead of HLT you will effectively ignore yield_on_hlt=0 setting. This is like having PV HLT that does not obey VMX exit control setting. -- Gleb. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
