On 21/01/21 01:19, Sean Christopherson wrote:
IMO, moving the lock to arch-specific code is bad for KVM. The
architectures' MMUs already diverge pretty horribly, and once things
diverge it's really hard to go the other direction. And this change,
along with all of the wrappers, thrash a lot of code and add a fair
amount of indirection without any real benefit to the other
architectures. What if we simply make the common mmu_lock a union? The
rwlock_t is probably a bit bigger, but that's a few bytes for an entire
VM. And maybe this would entice/inspire other architectures to move to a
similar MMU model.
I agree. Most architectures don't do the lockless tricks that x86 do,
and being able to lock for read would be better than nothing. For
example, I took a look at ARM and stage2_update_leaf_attrs could be
changed to operate in cmpxchg-like style while holding the rwlock for read.
Paolo
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index f3b1013fb22c..bbc8efd4af62 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -451,7 +451,10 @@ struct kvm_memslots {
};
struct kvm {
- spinlock_t mmu_lock;
+ union {
+ rwlock_t mmu_rwlock;
+ spinlock_t mmu_lock;
+ };
struct mutex slots_lock;
struct mm_struct *mm; /* userspace tied to this vm */
struct kvm_memslots __rcu *memslots[KVM_ADDRESS_SPACE_NUM];
