From: David Matlack <dmatlack@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Robert Hoo <robert.hu@linux.intel.com>,
Greg Thelen <gthelen@google.com>, Ben Gardon <bgardon@google.com>,
Mingwei Zhang <mizhang@google.com>
Subject: Re: [PATCH 5/5] KVM: x86/mmu: Move kvm_tdp_mmu_map()'s prolog and epilog to its caller
Date: Tue, 20 Dec 2022 09:53:39 -0800 [thread overview]
Message-ID: <Y6H2o2ADCALDA2oL@google.com> (raw)
In-Reply-To: <20221213033030.83345-6-seanjc@google.com>
On Tue, Dec 13, 2022 at 03:30:30AM +0000, Sean Christopherson wrote:
> Move the hugepage adjust, tracepoint, and RCU (un)lock logic out of
> kvm_tdp_mmu_map() and into its sole caller, kvm_tdp_mmu_page_fault(), to
> eliminate the gotos used to bounce through rcu_read_unlock() when bailing
> from the walk.
>
> Opportunistically mark kvm_mmu_hugepage_adjust() as static as
> kvm_tdp_mmu_map() was the only external user.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> arch/x86/kvm/mmu/mmu.c | 9 ++++++++-
> arch/x86/kvm/mmu/mmu_internal.h | 1 -
> arch/x86/kvm/mmu/tdp_mmu.c | 22 ++++------------------
> 3 files changed, 12 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 254bc46234e0..99c40617d325 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -3085,7 +3085,8 @@ int kvm_mmu_max_mapping_level(struct kvm *kvm,
> return min(host_level, max_level);
> }
>
> -void kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
> +static void kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu,
> + struct kvm_page_fault *fault)
> {
> struct kvm_memory_slot *slot = fault->slot;
> kvm_pfn_t mask;
> @@ -4405,7 +4406,13 @@ static int kvm_tdp_mmu_page_fault(struct kvm_vcpu *vcpu,
> if (is_page_fault_stale(vcpu, fault))
> goto out_unlock;
>
> + kvm_mmu_hugepage_adjust(vcpu, fault);
Can you also move the call to kvm_mmu_hugepage_adjust() from
direct_map() to direct_page_fault()? I do think it's worth the
maintenence burden to keep those functions consistent.
> +
> + trace_kvm_mmu_spte_requested(fault);
> +
> + rcu_read_lock();
> r = kvm_tdp_mmu_map(vcpu, fault);
> + rcu_read_unlock();
I would prefer to keep these in tdp_mmu.c, to reduce the amount of TDP
MMU details that bleed into mmu.c (RCU) and for consistency with other
TDP MMU APIs that don't require the caller to acquire RCU. This will
also be helpful for the Common MMU, as the tracepoint and RCU will be
common.
e.g.
static int __kvm_tdp_mmu_map(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
{
...
}
int kvm_tdp_mmu_map(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
{
int r;
trace_kvm_mmu_spte_requested(fault);
rcu_read_lock();
r = __kvm_tdp_mmu_map(vcpu, fault);
rcu_read_unlock();
return r;
}
next prev parent reply other threads:[~2022-12-20 17:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 3:30 [PATCH 0/5] KVM: x86/mmu: TDP MMU fixes for 6.2 Sean Christopherson
2022-12-13 3:30 ` [PATCH 1/5] KVM: x86/mmu: Don't attempt to map leaf if target TDP MMU SPTE is frozen Sean Christopherson
2022-12-14 11:57 ` Robert Hoo
2022-12-13 3:30 ` [PATCH 2/5] KVM: x86/mmu: Map TDP MMU leaf SPTE iff target level is reached Sean Christopherson
2022-12-13 3:30 ` [PATCH 3/5] KVM: x86/mmu: Re-check under lock that TDP MMU SP hugepage is disallowed Sean Christopherson
2022-12-14 11:58 ` Robert Hoo
2022-12-15 0:11 ` Sean Christopherson
2022-12-15 6:26 ` Robert Hoo
2022-12-13 3:30 ` [PATCH 4/5] KVM: x86/mmu: Don't install TDP MMU SPTE if SP has unexpected level Sean Christopherson
2022-12-13 17:59 ` David Matlack
2022-12-13 18:15 ` Sean Christopherson
2022-12-20 18:24 ` David Matlack
2022-12-13 3:30 ` [PATCH 5/5] KVM: x86/mmu: Move kvm_tdp_mmu_map()'s prolog and epilog to its caller Sean Christopherson
2022-12-20 17:53 ` David Matlack [this message]
2022-12-21 18:32 ` Sean Christopherson
2022-12-29 19:51 ` David Matlack
2022-12-29 21:06 ` Paolo Bonzini
2023-01-03 22:21 ` David Matlack
2022-12-14 12:01 ` [PATCH 0/5] KVM: x86/mmu: TDP MMU fixes for 6.2 Robert Hoo
2022-12-14 15:48 ` Sean Christopherson
2022-12-23 17:32 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y6H2o2ADCALDA2oL@google.com \
--to=dmatlack@google.com \
--cc=bgardon@google.com \
--cc=gthelen@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=robert.hu@linux.intel.com \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox