* Alexander Graf <[email protected]> [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 [email protected] https://lists.linuxfoundation.org/mailman/listinfo/virtualization
