lkml.org 
[lkml]   [2021]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 15/24] kvm: mmu: Wrap mmu_lock cond_resched and needbreak
Date
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];

\
 
 \ /
  Last update: 2021-01-21 21:22    [W:0.139 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site