From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH 9/9] KVM: x86/mmu: Track SPTE accessed info across mmu_notifier PROT changes
Date: Thu, 1 Aug 2024 11:34:53 -0700 [thread overview]
Message-ID: <20240801183453.57199-10-seanjc@google.com> (raw)
In-Reply-To: <20240801183453.57199-1-seanjc@google.com>
Preserve Accessed information when zapping SPTEs in response to an
mmu_notifier protection change, e.g. if KVM is zapping SPTEs because
NUMA balancing kicked in. KVM is not required to fully unmap the SPTE,
and the core VMA information isn't changing, i.e. the information is
still fresh and useful.
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/mmu/tdp_mmu.c | 31 +++++++++++++++++++++++++------
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index ac3200ce00f9..780f35a22c05 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -838,7 +838,8 @@ bool kvm_tdp_mmu_zap_sp(struct kvm *kvm, struct kvm_mmu_page *sp)
* operation can cause a soft lockup.
*/
static bool tdp_mmu_zap_leafs(struct kvm *kvm, struct kvm_mmu_page *root,
- gfn_t start, gfn_t end, bool can_yield, bool flush)
+ gfn_t start, gfn_t end, bool can_yield,
+ bool keep_accessed_bit, bool flush)
{
struct tdp_iter iter;
@@ -849,17 +850,29 @@ static bool tdp_mmu_zap_leafs(struct kvm *kvm, struct kvm_mmu_page *root,
rcu_read_lock();
for_each_tdp_pte_min_level(iter, root, PG_LEVEL_4K, start, end) {
+ u64 new_spte = SHADOW_NONPRESENT_VALUE;
+
if (can_yield &&
tdp_mmu_iter_cond_resched(kvm, &iter, flush, false)) {
flush = false;
continue;
}
+ /*
+ * Note, this will fail to clear non-present, accessed SPTEs,
+ * but that isn't a functional problem, it can only result in
+ * a _potential_ false positive in the unlikely scenario that
+ * the primary MMU zaps an hva, reinstalls a new hva, and ages
+ * the new hva, all before KVM accesses the hva.
+ */
if (!is_shadow_present_pte(iter.old_spte) ||
!is_last_spte(iter.old_spte, iter.level))
continue;
- tdp_mmu_iter_set_spte(kvm, &iter, SHADOW_NONPRESENT_VALUE);
+ if (keep_accessed_bit)
+ new_spte |= iter.old_spte & shadow_accessed_mask;
+
+ tdp_mmu_iter_set_spte(kvm, &iter, new_spte);
/*
* Zappings SPTEs in invalid roots doesn't require a TLB flush,
@@ -889,7 +902,7 @@ bool kvm_tdp_mmu_zap_leafs(struct kvm *kvm, gfn_t start, gfn_t end, bool flush)
lockdep_assert_held_write(&kvm->mmu_lock);
for_each_valid_tdp_mmu_root_yield_safe(kvm, root, -1)
- flush = tdp_mmu_zap_leafs(kvm, root, start, end, true, flush);
+ flush = tdp_mmu_zap_leafs(kvm, root, start, end, true, false, flush);
return flush;
}
@@ -1180,11 +1193,13 @@ int kvm_tdp_mmu_map(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
bool kvm_tdp_mmu_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range,
bool flush)
{
+ bool keep_a_bit = range->arg.event == MMU_NOTIFY_PROTECTION_VMA ||
+ range->arg.event == MMU_NOTIFY_PROTECTION_PAGE;
struct kvm_mmu_page *root;
__for_each_tdp_mmu_root_yield_safe(kvm, root, range->slot->as_id, false)
flush = tdp_mmu_zap_leafs(kvm, root, range->start, range->end,
- range->may_block, flush);
+ range->may_block, keep_a_bit, flush);
return flush;
}
@@ -1201,7 +1216,11 @@ static void kvm_tdp_mmu_age_spte(struct tdp_iter *iter)
{
u64 new_spte;
- if (spte_ad_enabled(iter->old_spte)) {
+ if (spte_ad_enabled(iter->old_spte) ||
+ !is_shadow_present_pte(iter->old_spte)) {
+ KVM_MMU_WARN_ON(!is_shadow_present_pte(iter->old_spte) &&
+ iter->old_spte != (SHADOW_NONPRESENT_VALUE | shadow_accessed_mask));
+
iter->old_spte = tdp_mmu_clear_spte_bits(iter->sptep,
iter->old_spte,
shadow_accessed_mask,
@@ -1235,7 +1254,7 @@ static bool __kvm_tdp_mmu_age_gfn_range(struct kvm *kvm,
for_each_valid_tdp_mmu_root(kvm, root, range->slot->as_id) {
rcu_read_lock();
- tdp_root_for_each_leaf_pte(iter, root, range->start, range->end) {
+ tdp_root_for_each_pte(iter, root, range->start, range->end) {
if (!is_accessed_spte(iter.old_spte))
continue;
--
2.46.0.rc1.232.g9752f9e123-goog
next prev parent reply other threads:[~2024-08-01 18:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 18:34 [RFC PATCH 0/9] KVM: x86/mmu: Preserve Accessed bits on PROT changes Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 1/9] KVM: x86/mmu: Add a dedicated flag to track if A/D bits are globally enabled Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 2/9] KVM: x86/mmu: Set shadow_accessed_mask for EPT even if A/D bits disabled Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 3/9] KVM: x86/mmu: Set shadow_dirty_mask " Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 4/9] KVM: x86/mmu: Use Accessed bit even when _hardware_ A/D bits are disabled Sean Christopherson
2024-08-05 16:49 ` David Matlack
2024-08-01 18:34 ` [RFC PATCH 5/9] KVM: x86/mmu: Free up A/D bits in FROZEN_SPTE Sean Christopherson
2024-08-05 7:20 ` Yuan Yao
2024-08-05 22:17 ` Sean Christopherson
2024-08-06 3:31 ` Yuan Yao
2024-08-01 18:34 ` [RFC PATCH 6/9] KVM: x86/mmu: Process only valid TDP MMU roots when aging a gfn range Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 7/9] KVM: x86/mmu: Stop processing TDP MMU roots for test_age if young SPTE found Sean Christopherson
2024-08-01 18:34 ` [RFC PATCH 8/9] KVM: Plumb mmu_notifier invalidation event type into arch code Sean Christopherson
2024-08-01 18:34 ` Sean Christopherson [this message]
2024-08-05 7:59 ` [RFC PATCH 9/9] KVM: x86/mmu: Track SPTE accessed info across mmu_notifier PROT changes Yuan Yao
2024-08-05 9:12 ` Yuan Yao
2024-08-07 6:41 ` Yuan Yao
2024-08-05 16:45 ` [RFC PATCH 0/9] KVM: x86/mmu: Preserve Accessed bits on " David Matlack
2024-08-05 20:11 ` Sean Christopherson
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=20240801183453.57199-10-seanjc@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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