Il 27/02/2014 13:11, David Vrabel ha scritto:
> This patch adds para-virtualization support to the queue spinlock code
> by enabling the queue head to kick the lock holder CPU, if known,
> in when the lock isn't released for a certain amount of time. It
> also enables the mutual monitoring of the queue head CPU and the
> following node CPU in the queue to make sure that their CPUs will
> stay scheduled in.
I'm not really understanding how this is supposed to work. There
appears to be an assumption that a guest can keep one of its VCPUs
running by repeatedly kicking it? This is not possible under Xen and I
doubt it's possible under KVM or any other hypervisor.
KVM allows any VCPU to wake up a currently halted VCPU of its choice,
see Documentation/virtual/kvm/hypercalls.txt.
5. KVM_HC_KICK_CPU
------------------------
Architecture: x86
Status: active
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 until occurrence 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 (a1) of the vcpu
to be woken up. An additional argument (a0) is used in the hypercall for
future use.
This is the same as a dummy IPI, but cheaper (about 2000 clock cycles
wasted on the source VCPU, and the latency on the destination is about
half; an IPI costs roughly the same on the source and much more on the
destination).
It looks like Xen could use an event channel.
Paolo
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
