From: Yan Zhao <yan.y.zhao@intel.com>
To: seanjc@google.com, pbonzini@redhat.com, kvm@vger.kernel.org,
rick.p.edgecombe@intel.com, kas@kernel.org
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
dave.hansen@intel.com, kai.huang@intel.com,
binbin.wu@linux.intel.com, xiaoyao.li@intel.com,
yan.y.zhao@intel.com
Subject: [PATCH v3 10/15] KVM: x86/mmu: Drop KVM_BUG_ON() on shared lock to zap child external PTEs
Date: Thu, 28 May 2026 16:12:37 +0800 [thread overview]
Message-ID: <20260528081237.10364-1-yan.y.zhao@intel.com> (raw)
In-Reply-To: <20260528080856.10141-1-yan.y.zhao@intel.com>
From: Rick Edgecombe <rick.p.edgecombe@intel.com>
Drop the KVM_BUG_ON() in the KVM MMU core before zapping child external
PTEs, since requiring zapping PTEs to be protected by exclusive mmu_lock is
TDX's specific requirement.
No need to plumb the shared/exclusive info into the remove_external_spte()
op or move the KVM_BUG_ON() to TDX, because
- There's already an assertion of exclusive mmu_lock protection in TDX.
- The KVM_BUG_ON() is a bit redundant given that if there's any bug causing
zapping of leaf PTEs in S-EPT under shared mmu_lock, SEAMCALL failures
due to contention would result in TDX_BUG_ON() in TDX.
Link: https://lore.kernel.org/kvm/aYUarHf3KEwHGuJe@google.com
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
---
MMU_refactors v3:
- Rebased to kvm-x86-next-2026.05.26.
MMU_refactors v2:
- Updated commit log and title. (Yan)
---
arch/x86/kvm/mmu/tdp_mmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index 3c3e73ce8da9..3ba7556a8d2f 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -473,10 +473,8 @@ static void handle_removed_pt(struct kvm *kvm, tdp_ptep_t pt, bool shared)
}
handle_changed_spte(kvm, sp, gfn, old_spte, FROZEN_SPTE, level, shared);
- if (is_mirror_sp(sp)) {
- KVM_BUG_ON(shared, kvm);
+ if (is_mirror_sp(sp))
remove_external_spte(kvm, gfn, old_spte, level);
- }
}
if (is_mirror_sp(sp) &&
--
2.43.2
next prev parent reply other threads:[~2026-05-28 8:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 8:08 [PATCH v3 00/15] TDX MMU refactors Yan Zhao
2026-05-28 8:10 ` [PATCH v3 01/15] KVM: TDX: Drop kvm_x86_ops.link_external_spt() Yan Zhao
2026-05-28 8:11 ` [PATCH v3 02/15] KVM: TDX: Wrap mapping of leaf and non-leaf S-EPT entries into helpers Yan Zhao
2026-05-28 8:11 ` [PATCH v3 03/15] KVM: x86/mmu: Fold set_external_spte_present() into its sole caller Yan Zhao
2026-05-28 8:11 ` [PATCH v3 04/15] KVM: x86/mmu: Plumb param "old_spte" into kvm_x86_ops.set_external_spte() Yan Zhao
2026-05-28 8:11 ` [PATCH v3 05/15] KVM: TDX: Move KVM_BUG_ON()s in __tdp_mmu_set_spte_atomic() to TDX code Yan Zhao
2026-05-28 9:45 ` sashiko-bot
2026-05-28 8:11 ` [PATCH v3 06/15] KVM: TDX: Move lockdep assert " Yan Zhao
2026-05-28 8:12 ` [PATCH v3 07/15] KVM: x86/tdp_mmu: Morph !is_frozen_spte() check into a KVM_MMU_WARN_ON() Yan Zhao
2026-05-28 8:12 ` [PATCH v3 08/15] KVM: x86/mmu: Plumb "sp" _pointer_ into the TDP MMU's handle_changed_spte() Yan Zhao
2026-05-28 8:12 ` [PATCH v3 09/15] KVM: x86/tdp_mmu: Centrally propagate to-present/atomic zap updates to external PTEs Yan Zhao
2026-05-28 9:52 ` sashiko-bot
2026-05-28 8:12 ` Yan Zhao [this message]
2026-05-28 8:12 ` [PATCH v3 11/15] KVM: TDX: Hoist tdx_sept_remove_private_spte() above set_private_spte() Yan Zhao
2026-05-28 8:12 ` [PATCH v3 12/15] KVM: TDX: Drop kvm_x86_ops.remove_external_spte() Yan Zhao
2026-05-28 8:13 ` [PATCH v3 13/15] KVM: TDX: Rename tdx_sept_remove_private_spte() to show it's for leaf SPTEs Yan Zhao
2026-05-28 8:13 ` [PATCH v3 14/15] KVM: x86: Move error handling inside free_external_spt() Yan Zhao
2026-05-28 8:13 ` [PATCH v3 15/15] KVM: TDX: Move external page table freeing to TDX code Yan Zhao
2026-05-28 13:03 ` [PATCH v3 00/15] TDX MMU refactors Sean Christopherson
2026-05-29 5:34 ` 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=20260528081237.10364-1-yan.y.zhao@intel.com \
--to=yan.y.zhao@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=kai.huang@intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.