Skip to content

Commit 5dd4e19

Browse files
Maxim Levitskybonzini
authored andcommitted
KVM: add kvm_lock_all_vcpus and kvm_trylock_all_vcpus
JIRA: https://issues.redhat.com/browse/RHEL-95318 commit e4a454c Author: Maxim Levitsky <mlevitsk@redhat.com> Date: Mon May 12 14:04:04 2025 -0400 KVM: add kvm_lock_all_vcpus and kvm_trylock_all_vcpus In a few cases, usually in the initialization code, KVM locks all vCPUs of a VM to ensure that userspace doesn't do funny things while KVM performs an operation that affects the whole VM. Until now, all these operations were implemented using custom code, and all of them share the same problem: Lockdep can't cope with simultaneous locking of a large number of locks of the same class. However if these locks are taken while another lock is already held, which is luckily the case, it is possible to take advantage of little known _nest_lock feature of lockdep which allows in this case to have an unlimited number of locks of same class to be taken. To implement this, create two functions: kvm_lock_all_vcpus() and kvm_trylock_all_vcpus() Both functions are needed because some code that will be replaced in the subsequent patches, uses mutex_trylock, instead of regular mutex_lock. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Message-ID: <20250512180407.659015-4-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
1 parent 32f4a5c commit 5dd4e19

File tree

2 files changed

+63
-0
lines changed

2 files changed

+63
-0
lines changed

include/linux/kvm_host.h

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1008,6 +1008,10 @@ static inline struct kvm_vcpu *kvm_get_vcpu_by_id(struct kvm *kvm, int id)
10081008

10091009
void kvm_destroy_vcpus(struct kvm *kvm);
10101010

1011+
int kvm_trylock_all_vcpus(struct kvm *kvm);
1012+
int kvm_lock_all_vcpus(struct kvm *kvm);
1013+
void kvm_unlock_all_vcpus(struct kvm *kvm);
1014+
10111015
void vcpu_load(struct kvm_vcpu *vcpu);
10121016
void vcpu_put(struct kvm_vcpu *vcpu);
10131017

virt/kvm/kvm_main.c

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1430,6 +1430,65 @@ static int kvm_vm_release(struct inode *inode, struct file *filp)
14301430
return 0;
14311431
}
14321432

1433+
int kvm_trylock_all_vcpus(struct kvm *kvm)
1434+
{
1435+
struct kvm_vcpu *vcpu;
1436+
unsigned long i, j;
1437+
1438+
lockdep_assert_held(&kvm->lock);
1439+
1440+
kvm_for_each_vcpu(i, vcpu, kvm)
1441+
if (!mutex_trylock_nest_lock(&vcpu->mutex, &kvm->lock))
1442+
goto out_unlock;
1443+
return 0;
1444+
1445+
out_unlock:
1446+
kvm_for_each_vcpu(j, vcpu, kvm) {
1447+
if (i == j)
1448+
break;
1449+
mutex_unlock(&vcpu->mutex);
1450+
}
1451+
return -EINTR;
1452+
}
1453+
EXPORT_SYMBOL_GPL(kvm_trylock_all_vcpus);
1454+
1455+
int kvm_lock_all_vcpus(struct kvm *kvm)
1456+
{
1457+
struct kvm_vcpu *vcpu;
1458+
unsigned long i, j;
1459+
int r;
1460+
1461+
lockdep_assert_held(&kvm->lock);
1462+
1463+
kvm_for_each_vcpu(i, vcpu, kvm) {
1464+
r = mutex_lock_killable_nest_lock(&vcpu->mutex, &kvm->lock);
1465+
if (r)
1466+
goto out_unlock;
1467+
}
1468+
return 0;
1469+
1470+
out_unlock:
1471+
kvm_for_each_vcpu(j, vcpu, kvm) {
1472+
if (i == j)
1473+
break;
1474+
mutex_unlock(&vcpu->mutex);
1475+
}
1476+
return r;
1477+
}
1478+
EXPORT_SYMBOL_GPL(kvm_lock_all_vcpus);
1479+
1480+
void kvm_unlock_all_vcpus(struct kvm *kvm)
1481+
{
1482+
struct kvm_vcpu *vcpu;
1483+
unsigned long i;
1484+
1485+
lockdep_assert_held(&kvm->lock);
1486+
1487+
kvm_for_each_vcpu(i, vcpu, kvm)
1488+
mutex_unlock(&vcpu->mutex);
1489+
}
1490+
EXPORT_SYMBOL_GPL(kvm_unlock_all_vcpus);
1491+
14331492
/*
14341493
* Allocation size is twice as large as the actual dirty bitmap size.
14351494
* See kvm_vm_ioctl_get_dirty_log() why this is needed.

0 commit comments

Comments
 (0)