From: Yan Zhao <yan.y.zhao@intel.com>
To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: pbonzini@redhat.com, seanjc@google.com, Yan Zhao <yan.y.zhao@intel.com>
Subject: [PATCH] KVM: x86: Zap all TDP leaf entries according noncoherent DMA count
Date: Mon, 8 May 2023 11:47:00 +0800 [thread overview]
Message-ID: <20230508034700.7686-1-yan.y.zhao@intel.com> (raw)
Zap all TDP leaf entries when noncoherent DMA count goes from 0 to !0, or
from !0 to 0.
When there's no noncoherent DMA device, EPT memory type is
((MTRR_TYPE_WRBACK << VMX_EPT_MT_EPTE_SHIFT) | VMX_EPT_IPAT_BIT)
When there're noncoherent DMA devices, EPT memory type needs to honor
guest CR0_CD and MTRR settings.
So, if noncoherent DMA count changes between 0 and !0, EPT leaf entries
need to be zapped to clear stale memory type.
This issue might be hidden when VFIO adding/removing MMIO regions of the
noncoherent DMA devices on device attaching/de-attaching because
usually the MMIO regions will be disabled/enabled for several times during
guest PCI probing. And in KVM, TDP entries are all zapped on memslot
removal.
However, this issue may appear when kvm_mmu_zap_all_fast() is not called
before KVM slot removal, e.g. as for TDX, only leaf entries for the
memslot to be removed is zapped.
static void kvm_mmu_invalidate_zap_pages_in_memslot(struct kvm *kvm,
struct kvm_memory_slot *slot,
struct kvm_page_track_notifier_node *node)
{
if (kvm_gfn_shared_mask(kvm))
/*
* Secure-EPT requires to release PTs from the leaf. The
* optimization to zap root PT first with child PT doesn't
* work.
*/
kvm_mmu_zap_memslot(kvm, slot);
else
kvm_mmu_zap_all_fast(kvm);
}
And even without TDX's case, in some extreme conditions if MMIO regions
are not disabled during device attaching, e.g. if guest does not cause
the MMIO region disabling in QEMU.
Then TDP zap will not be called and wrong EPT memory type might be
retained.
So, do the TDP zapping of all leaf entries when present/non-present state
of noncoherent DMA devices changes to ensure stale entries cleaned away.
And as this is not a frequent operation, the extra zap should be fine.
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
---
arch/x86/kvm/x86.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e7f78fe79b32..99a825722d95 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -13145,13 +13145,15 @@ EXPORT_SYMBOL_GPL(kvm_arch_has_assigned_device);
void kvm_arch_register_noncoherent_dma(struct kvm *kvm)
{
- atomic_inc(&kvm->arch.noncoherent_dma_count);
+ if (atomic_inc_return(&kvm->arch.noncoherent_dma_count) == 1)
+ kvm_zap_gfn_range(kvm, gpa_to_gfn(0), gpa_to_gfn(~0ULL));
}
EXPORT_SYMBOL_GPL(kvm_arch_register_noncoherent_dma);
void kvm_arch_unregister_noncoherent_dma(struct kvm *kvm)
{
- atomic_dec(&kvm->arch.noncoherent_dma_count);
+ if (!atomic_dec_return(&kvm->arch.noncoherent_dma_count))
+ kvm_zap_gfn_range(kvm, gpa_to_gfn(0), gpa_to_gfn(~0ULL));
}
EXPORT_SYMBOL_GPL(kvm_arch_unregister_noncoherent_dma);
--
2.17.1
next reply other threads:[~2023-05-08 4:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 3:47 Yan Zhao [this message]
2023-05-08 7:19 ` [PATCH] KVM: x86: Zap all TDP leaf entries according noncoherent DMA count Chao Gao
2023-05-09 1:40 ` Yan Zhao
2023-05-09 3:11 ` Chao Gao
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=20230508034700.7686-1-yan.y.zhao@intel.com \
--to=yan.y.zhao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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