[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YGT2AV6lhDG5yLkW@google.com>
Date: Wed, 31 Mar 2021 22:21:53 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Ben Gardon <bgardon@...gle.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>,
Peter Xu <peterx@...hat.com>, Peter Shier <pshier@...gle.com>,
Peter Feiner <pfeiner@...gle.com>,
Junaid Shahid <junaids@...gle.com>,
Jim Mattson <jmattson@...gle.com>,
Yulei Zhang <yulei.kernel@...il.com>,
Wanpeng Li <kernellwp@...il.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Xiao Guangrong <xiaoguangrong.eric@...il.com>
Subject: Re: [PATCH 07/13] KVM: x86/mmu: Make TDP MMU root refcount atomic
On Wed, Mar 31, 2021, Ben Gardon wrote:
> In order to parallelize more operations for the TDP MMU, make the
> refcount on TDP MMU roots atomic, so that a future patch can allow
> multiple threads to take a reference on the root concurrently, while
> holding the MMU lock in read mode.
>
> Signed-off-by: Ben Gardon <bgardon@...gle.com>
> ---
...
> @@ -88,10 +88,12 @@ static struct kvm_mmu_page *tdp_mmu_next_root(struct kvm *kvm,
> next_root = list_first_entry(&kvm->arch.tdp_mmu_roots,
> typeof(*next_root), link);
>
> + while (!list_entry_is_head(next_root, &kvm->arch.tdp_mmu_roots, link) &&
> + !kvm_tdp_mmu_get_root(kvm, next_root))
> + next_root = list_next_entry(next_root, link);
> +
> if (list_entry_is_head(next_root, &kvm->arch.tdp_mmu_roots, link))
> next_root = NULL;
> - else
> - kvm_tdp_mmu_get_root(kvm, next_root);
>
> if (prev_root)
> kvm_tdp_mmu_put_root(kvm, prev_root);
> @@ -158,14 +160,13 @@ hpa_t kvm_tdp_mmu_get_vcpu_root_hpa(struct kvm_vcpu *vcpu)
>
> /* Check for an existing root before allocating a new one. */
> for_each_tdp_mmu_root(kvm, root) {
> - if (root->role.word == role.word) {
> - kvm_tdp_mmu_get_root(kvm, root);
> + if (root->role.word == role.word &&
> + kvm_tdp_mmu_get_root(kvm, root))
I'm not opposed to changing this logic while making the refcount atomic, but it
needs to be explained in the changelog. As is, the changelog makes it sound
like the patch is a pure refactoring of the type.
Powered by blists - more mailing lists