* Alexander Graf <agraf@xxxxxxx> [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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
