From mboxrd@z Thu Jan 1 00:00:00 1970 From: Srivatsa Vaddagiri Subject: Re: [PATCH RFC V4 5/5] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock Date: Tue, 17 Jan 2012 18:41:03 +0530 Message-ID: <20120117131103.GD30398@linux.vnet.ibm.com> References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com> <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com> <4F13E739.7040300@redhat.com> <20120116094020.GA6019@linux.vnet.ibm.com> <4F13F883.5090002@redhat.com> <20120116141117.GB6019@linux.vnet.ibm.com> <20120117091413.GM2167@redhat.com> <20120117122650.GC30757@linux.vnet.ibm.com> <20120117125126.GQ2167@redhat.com> Reply-To: Srivatsa Vaddagiri Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , Raghavendra K T , KVM , linux-doc@vger.kernel.org, Peter Zijlstra , Jan Kiszka , Virtualization , Paul Mackerras , "H. Peter Anvin" , Stefano Stabellini , Xen , Dave Jiang , Glauber Costa , X86 , Ingo Molnar , Avi Kivity , Rik van Riel , Konrad Rzeszutek Wilk , Sasha Levin , Sedat Dilek , Thomas Gleixner , Greg Kroah-Hartman , LKML , Dave Hansen Return-path: Content-Disposition: inline In-Reply-To: <20120117125126.GQ2167@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: kvm.vger.kernel.org * Gleb Natapov [2012-01-17 14:51:26]: > On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote: > > * Gleb Natapov [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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Srivatsa Vaddagiri Subject: Re: [PATCH RFC V4 5/5] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock Date: Tue, 17 Jan 2012 18:41:03 +0530 Message-ID: <20120117131103.GD30398@linux.vnet.ibm.com> References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com> <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com> <4F13E739.7040300@redhat.com> <20120116094020.GA6019@linux.vnet.ibm.com> <4F13F883.5090002@redhat.com> <20120116141117.GB6019@linux.vnet.ibm.com> <20120117091413.GM2167@redhat.com> <20120117122650.GC30757@linux.vnet.ibm.com> <20120117125126.GQ2167@redhat.com> Reply-To: Srivatsa Vaddagiri Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20120117125126.GQ2167@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Gleb Natapov Cc: Jeremy Fitzhardinge , Raghavendra K T , KVM , linux-doc@vger.kernel.org, Peter Zijlstra , Jan Kiszka , Virtualization , Paul Mackerras , "H. Peter Anvin" , Stefano Stabellini , Xen , Dave Jiang , Glauber Costa , X86 , Ingo Molnar , Avi Kivity , Rik van Riel , Konrad Rzeszutek Wilk , Sasha Levin , Sedat Dilek , Thomas Gleixner , Greg Kroah-Hartman , LKML Dave Hansen List-Id: virtualization@lists.linuxfoundation.org * Gleb Natapov [2012-01-17 14:51:26]: > On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote: > > * Gleb Natapov [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