Commit c0093f1a authored Nov 20, 2017 by Paul Mackerras

KVM: PPC: Book3S HV: Fix conditions for starting vcpu



This corrects the test that determines whether a vcpu that has just
become able to run in the guest (e.g. it has just finished handling
a hypercall or hypervisor page fault) and whose virtual core is
already running somewhere as a "piggybacked" vcore can start
immediately or not.  (A piggybacked vcore is one which is executing
along with another vcore as a result of dynamic micro-threading.)

Previously the test tried to lock the piggybacked vcore using
spin_trylock, which would always fail because the vcore was already
locked, and so the vcpu would have to wait until its vcore exited
the guest before it could enter.

In fact the vcpu can enter if its vcore is in VCORE_PIGGYBACK state
and not already exiting (or exited) the guest, so the test in
VCORE_PIGGYBACK state is basically the same as for VCORE_RUNNING
state.

Coverity detected this as a double unlock issue, which it isn't
because the spin_trylock would always fail.  This will fix the
apparent double unlock as well.

Signed-off-by: Paul Mackerras <paulus@ozlabs.org>

parent 4fcf361d

arch/powerpc/kvm/book3s_hv.c

+2 −11

Original line number	Diff line number	Diff line
		@@ -3175,17 +3175,8 @@ static int kvmppc_run_vcpu(struct kvm_run kvm_run, struct kvm_vcpu vcpu)
		* this thread straight away and have it join in.
		*/
		if (!signal_pending(current)) {
		if (vc->vcore_state == VCORE_PIGGYBACK) {
		if (spin_trylock(&vc->lock)) {
		if (vc->vcore_state == VCORE_RUNNING &&
		!VCORE_IS_EXITING(vc)) {
		kvmppc_create_dtl_entry(vcpu, vc);
		kvmppc_start_thread(vcpu, vc);
		trace_kvm_guest_enter(vcpu);
		}
		spin_unlock(&vc->lock);
		}
		} else if (vc->vcore_state == VCORE_RUNNING &&
		if ((vc->vcore_state == VCORE_PIGGYBACK \|\|
		vc->vcore_state == VCORE_RUNNING) &&
		!VCORE_IS_EXITING(vc)) {
		kvmppc_create_dtl_entry(vcpu, vc);
		kvmppc_start_thread(vcpu, vc);

Admin message