KVM: PPC: Book3S HV: Fix conditions for starting vcpu
authorPaul Mackerras <paulus@ozlabs.org>
Mon, 20 Nov 2017 05:12:25 +0000 (16:12 +1100)
committerPaul Mackerras <paulus@ozlabs.org>
Thu, 23 Nov 2017 03:23:22 +0000 (14:23 +1100)
commitc0093f1a38a0fd6c32a2269f0533bb13fb95143d
treea9505f4667cdf33316eb87ef10977c68b3a16d95
parent4fcf361dbdbdb43038bb173e2391c4073e713745
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>
arch/powerpc/kvm/book3s_hv.c