From: "Huang, Kai" <kai.huang@intel.com>
To: "pbonzini@redhat.com" <pbonzini@redhat.com>, "Christopherson,,
Sean" <seanjc@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>
Subject: Re: [PATCH 2/2] KVM: x86/mmu: Retry fault before acquiring mmu_lock if mapping is changing
Date: Wed, 6 Sep 2023 23:03:06 +0000 [thread overview]
Message-ID: <68859513bc0fb4eda4e3e62ec073dd2a58f7676b.camel@intel.com> (raw)
In-Reply-To: <20230825020733.2849862-3-seanjc@google.com>
On Thu, 2023-08-24 at 19:07 -0700, Sean Christopherson wrote:
> Retry page faults without acquiring mmu_lock if the resolved hva is covered
> by an active invalidation. Contending for mmu_lock is especially
> problematic on preemptible kernels as the mmu_notifier invalidation task
> will yield mmu_lock (see rwlock_needbreak()), delay the in-progress
> invalidation, and ultimately increase the latency of resolving the page
> fault. And in the worst case scenario, yielding will be accompanied by a
> remote TLB flush, e.g. if the invalidation covers a large range of memory
> and vCPUs are accessing addresses that were already zapped.
>
> Alternatively, the yielding issue could be mitigated by teaching KVM's MMU
> iterators to perform more work before yielding, but that wouldn't solve
> the lock contention and would negatively affect scenarios where a vCPU is
> trying to fault in an address that is NOT covered by the in-progress
> invalidation.
>
> Reported-by: Yan Zhao <yan.y.zhao@intel.com>
> Closes: https://lore.kernel.org/all/ZNnPF4W26ZbAyGto@yzhao56-desk.sh.intel.com
> Signed-off-by: Sean Christopherson <seanjc@google.com>
Acked-by: Kai Huang <kai.huang@intel.com>
Nit below ...
> ---
> arch/x86/kvm/mmu/mmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 1a5a1e7d1eb7..8e2e07ed1a1b 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -4334,6 +4334,9 @@ static int kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault,
> if (unlikely(!fault->slot))
> return kvm_handle_noslot_fault(vcpu, fault, access);
>
> + if (mmu_invalidate_retry_hva(vcpu->kvm, fault->mmu_seq, fault->hva))
> + return RET_PF_RETRY;
> +
... Perhaps a comment saying this is to avoid unnecessary MMU lock contention
would be nice. Otherwise we have is_page_fault_stale() called later within the
MMU lock. I suppose people only tend to use git blamer when they cannot find
answer in the code :-)
> return RET_PF_CONTINUE;
> }
>
Btw, currently fault->mmu_seq is set in kvm_faultin_pfn(), which happens after
fast_page_fault(). Conceptually, should we move this to even before
fast_page_fault() because I assume the range zapping should also apply to the
cases that fast_page_fault() handles?
next prev parent reply other threads:[~2023-09-06 23:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-25 2:07 [PATCH 0/2] KVM: Pre-check mmu_notifier retry on x86 Sean Christopherson
2023-08-25 2:07 ` [PATCH 1/2] KVM: Allow calling mmu_invalidate_retry_hva() without holding mmu_lock Sean Christopherson
2023-09-07 23:30 ` Huang, Kai
2023-09-08 17:36 ` Sean Christopherson
2023-08-25 2:07 ` [PATCH 2/2] KVM: x86/mmu: Retry fault before acquiring mmu_lock if mapping is changing Sean Christopherson
2023-09-06 23:03 ` Huang, Kai [this message]
2023-09-07 14:45 ` Sean Christopherson
2023-09-07 22:34 ` Huang, Kai
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=68859513bc0fb4eda4e3e62ec073dd2a58f7676b.camel@intel.com \
--to=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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