diff mbox series

[12/54] KVM: x86/mmu: Drop the intermediate "transient" __kvm_sync_page()

Message ID 20210622175739.3610207-13-seanjc@google.com (mailing list archive)
State New, archived
Headers show
Series KVM: x86/mmu: Bug fixes and summer cleaning | expand

Commit Message

Sean Christopherson June 22, 2021, 5:56 p.m. UTC
Nove the kvm_unlink_unsync_page() call out of kvm_sync_page() and into
it's sole caller, and fold __kvm_sync_page() into kvm_sync_page() since
the latter becomes a pure pass-through.  There really should be no reason
for code to do a complete sync of a shadow page outside of the full
kvm_mmu_sync_roots(), e.g. the one use case that creeped in turned out to
be flawed and counter-productive.

Update the comment in kvm_mmu_get_page() regarding its sync_page() usage,
which is anything but obvious.

Drop the stale comment about @sp->gfn needing to be write-protected, as
it directly contradicts the kvm_mmu_get_page() usage.

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/mmu/mmu.c | 36 +++++++++++++++++++-----------------
 1 file changed, 19 insertions(+), 17 deletions(-)

Comments

Paolo Bonzini June 23, 2021, 4:54 p.m. UTC | #1
On 22/06/21 19:56, Sean Christopherson wrote:
> @@ -2008,10 +2001,19 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
>   			goto trace_get_page;
>   
>   		if (sp->unsync) {
> -			/* The page is good, but __kvm_sync_page might still end
> -			 * up zapping it.  If so, break in order to rebuild it.
> +			/*
> +			 * The page is good, but is stale.  "Sync" the page to
> +			 * get the latest guest state, but don't write-protect
> +			 * the page and don't mark it synchronized!  KVM needs
> +			 * to ensure the mapping is valid, but doesn't need to
> +			 * fully sync (write-protect) the page until the guest
> +			 * invalidates the TLB mapping.  This allows multiple
> +			 * SPs for a single gfn to be unsync.
> +			 *
> +			 * If the sync fails, the page is zapped.  If so, break
> +			 * If so, break in order to rebuild it.
>   			 */

This should be a separate patch I think.  In addition it should point out the
place where write protection does happen, which is mmu_unsync_children:

                         /*
                          * The page is good, but is stale.  kvm_sync_page does
                          * get the latest guest state, but (unlike mmu_unsync_children)
                          * it doesn't write-protect the page or mark it synchronized!
                          * This way the validity of the mapping is ensured, but the
                          * overhead of write protection is not incurred until the
                          * guest invalidates the TLB mapping.  This allows multiple
                          * SPs for a single gfn to be unsync.
                          *
                          * If the sync fails, the page is zapped.  If so, break
                          * in order to rebuild it.
                          */

Paolo
diff mbox series

Patch

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 2e2d66319325..77296ce6215f 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1780,18 +1780,6 @@  static void kvm_mmu_commit_zap_page(struct kvm *kvm,
 	  &(_kvm)->arch.mmu_page_hash[kvm_page_table_hashfn(_gfn)])	\
 		if ((_sp)->gfn != (_gfn) || (_sp)->role.direct) {} else
 
-/* @sp->gfn should be write-protected at the call site */
-static bool __kvm_sync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
-			    struct list_head *invalid_list)
-{
-	if (vcpu->arch.mmu->sync_page(vcpu, sp) == 0) {
-		kvm_mmu_prepare_zap_page(vcpu->kvm, sp, invalid_list);
-		return false;
-	}
-
-	return true;
-}
-
 static bool kvm_mmu_remote_flush_or_zap(struct kvm *kvm,
 					struct list_head *invalid_list,
 					bool remote_flush)
@@ -1833,8 +1821,12 @@  static bool is_obsolete_sp(struct kvm *kvm, struct kvm_mmu_page *sp)
 static bool kvm_sync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp,
 			 struct list_head *invalid_list)
 {
-	kvm_unlink_unsync_page(vcpu->kvm, sp);
-	return __kvm_sync_page(vcpu, sp, invalid_list);
+	if (vcpu->arch.mmu->sync_page(vcpu, sp) == 0) {
+		kvm_mmu_prepare_zap_page(vcpu->kvm, sp, invalid_list);
+		return false;
+	}
+
+	return true;
 }
 
 struct mmu_page_path {
@@ -1931,6 +1923,7 @@  static void mmu_sync_children(struct kvm_vcpu *vcpu,
 		}
 
 		for_each_sp(pages, sp, parents, i) {
+			kvm_unlink_unsync_page(vcpu->kvm, sp);
 			flush |= kvm_sync_page(vcpu, sp, &invalid_list);
 			mmu_pages_clear_parents(&parents);
 		}
@@ -2008,10 +2001,19 @@  static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
 			goto trace_get_page;
 
 		if (sp->unsync) {
-			/* The page is good, but __kvm_sync_page might still end
-			 * up zapping it.  If so, break in order to rebuild it.
+			/*
+			 * The page is good, but is stale.  "Sync" the page to
+			 * get the latest guest state, but don't write-protect
+			 * the page and don't mark it synchronized!  KVM needs
+			 * to ensure the mapping is valid, but doesn't need to
+			 * fully sync (write-protect) the page until the guest
+			 * invalidates the TLB mapping.  This allows multiple
+			 * SPs for a single gfn to be unsync.
+			 *
+			 * If the sync fails, the page is zapped.  If so, break
+			 * If so, break in order to rebuild it.
 			 */
-			if (!__kvm_sync_page(vcpu, sp, &invalid_list))
+			if (!kvm_sync_page(vcpu, sp, &invalid_list))
 				break;
 
 			WARN_ON(!list_empty(&invalid_list));