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: Mon, 16 Jan 2012 09:21:14 +0530 Message-ID: <20120116035114.GI9129@linux.vnet.ibm.com> References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com> <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.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: 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: Alexander Graf Cc: Jeremy Fitzhardinge , Raghavendra K T , linux-doc@vger.kernel.org, Peter Zijlstra , Jan Kiszka , Virtualization , Paul Mackerras , "H. Peter Anvin" , Stefano Stabellini , Xen , Dave Jiang , KVM , 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 * Alexander Graf [2012-01-16 04:23:24]: > > +5. KVM_HC_KICK_CPU > > +------------------------ > > +value: 5 > > +Architecture: x86 > > +Purpose: Hypercall used to wakeup a vcpu from HLT state > > + > > +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest > > +kernel mode for an event to occur (ex: a spinlock to become available) > > +can execute HLT instruction once it has busy-waited for more than a > > +threshold time-interval. Execution of HLT instruction would cause > > +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence > > +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping > > +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be > > +wokenup. > > The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu. Hmm ..the hypercall does not allow a vcpu to yield. It just allows some target vcpu to be prodded/wokenup, after which vcpu continues execution. Note that semantics of this hypercall is different from the hypercall on which PPC pv-spinlock (__spin_yield()) is currently dependent. This is mainly because of ticketlocks on x86 (which does not allow us to easily store owning cpu details in lock word itself). > The APIC piece is an implementation detail for x86. On PPC we could just use the PIR register contents (processor identifier). - vatsa