From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
leiyang@redhat.com, rick.p.edgecombe@intel.com
Subject: Re: [PATCH] KVM: x86/mmu: Treat TDP MMU faults as spurious if access is already allowed
Date: Fri, 20 Dec 2024 07:55:16 -0800 [thread overview]
Message-ID: <Z2WTZGHmPDXHSrTA@google.com> (raw)
In-Reply-To: <Z2Th31I/0O/HY/Mb@yzhao56-desk.sh.intel.com>
On Fri, Dec 20, 2024, Yan Zhao wrote:
> > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> > index 4508d868f1cd..2f15e0e33903 100644
> > --- a/arch/x86/kvm/mmu/tdp_mmu.c
> > +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> > @@ -985,6 +985,11 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu,
> > if (fault->prefetch && is_shadow_present_pte(iter->old_spte))
> > return RET_PF_SPURIOUS;
> >
> > + if (is_shadow_present_pte(iter->old_spte) &&
> > + is_access_allowed(fault, iter->old_spte) &&
> > + is_last_spte(iter->old_spte, iter->level))
> One nit:
> Do we need to warn on pfn_changed?
Hmm, I definitely don't think we "need" to, but it's not a bad idea. The shadow
MMU kinda sorta WARNs on this scenario:
if (!was_rmapped) {
WARN_ON_ONCE(ret == RET_PF_SPURIOUS);
rmap_add(vcpu, slot, sptep, gfn, pte_access);
}
My only hesitation in adding a WARN is that the fast page fault path has similar
logic and doesn't WARN, but that's rather silly on my part because it ideally
would WARN, but grabbing the PFN to WARN would make it not-fast :-)
Want to post a patch? I don't really want to squeeze the WARN into 6.13, just
in case there's some weird edge case we're forgetting.
next prev parent reply other threads:[~2024-12-20 15:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 21:36 [PATCH] KVM: x86/mmu: Treat TDP MMU faults as spurious if access is already allowed Sean Christopherson
2024-12-19 2:40 ` Sean Christopherson
2024-12-19 14:55 ` Lei Yang
2024-12-20 3:17 ` Yan Zhao
2024-12-20 15:55 ` Sean Christopherson [this message]
2024-12-23 5:30 ` Yan Zhao
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=Z2WTZGHmPDXHSrTA@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=leiyang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=yan.y.zhao@intel.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