KVM: s390: protect VCPU cpu timer with a seqcount
authorDavid Hildenbrand <dahi@linux.vnet.ibm.com>
Wed, 17 Feb 2016 20:53:33 +0000 (21:53 +0100)
committerChristian Borntraeger <borntraeger@de.ibm.com>
Tue, 8 Mar 2016 12:57:53 +0000 (13:57 +0100)
commit9c23a1318eb12fcf76d9f663d2c3d88598e62a55
tree54451983c32ccdc6e28bfa58f69f0d5ebd1438f6
parentdb0758b29709815d93a963e31e2ec87ecf74f8bd
KVM: s390: protect VCPU cpu timer with a seqcount

For now, only the owning VCPU thread (that has loaded the VCPU) can get a
consistent cpu timer value when calculating the delta. However, other
threads might also be interested in a more recent, consistent value. Of
special interest will be the timer callback of a VCPU that executes without
having the VCPU loaded and could run in parallel with the VCPU thread.

The cpu timer has a nice property: it is only updated by the owning VCPU
thread. And speaking about accounting, a consistent value can only be
calculated by looking at cputm_start and the cpu timer itself in
one shot, otherwise the result might be wrong.

As we only have one writing thread at a time (owning VCPU thread), we can
use a seqcount instead of a seqlock and retry if the VCPU refreshed its
cpu timer. This avoids any heavy locking and only introduces a counter
update/check plus a handful of smp_wmb().

The owning VCPU thread should never have to retry on reads, and also for
other threads this might be a very rare scenario.

Please note that we have to use the raw_* variants for locking the seqcount
as lockdep will produce false warnings otherwise. The rq->lock held during
vcpu_load/put is also acquired from hardirq context. Lockdep cannot know
that we avoid potential deadlocks by disabling preemption and thereby
disable concurrent write locking attempts (via vcpu_put/load).

Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
arch/s390/include/asm/kvm_host.h
arch/s390/kvm/kvm-s390.c