Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Marco Marangoni <mamarang@amazon.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	 "cc-open-source@amazon.com" <cc-open-source@amazon.com>,
	James Houghton <jthoughton@google.com>
Subject: Re: [PATCH 3/4] KVM: x86/mmu: Add automatic prefaulting/prefetching for TDP MMU faults
Date: Fri, 30 Oct 2026 12:02:49 -0700	[thread overview]
Message-ID: <auTp2Yp2qtqtiPkX@google.com> (raw)
In-Reply-To: <MRWPR06MB107263BB1EF5464326E45DCD7B96D2@MRWPR06MB10726.eurprd06.prod.outlook.com>

On Fri, Oct 30, 2026, Marco Marangoni wrote:
> 
> On Thu, Oct 29, 2026, Sean Christopherson wrote:
> >> From my perspective, using fast GUP has the problem that you cannot prefault
> >> "around" your page, but just ahead of it, so I don't mind going with normal
> >> GUP if it makes things easier for you.
> >
> > I think I'm missing something, why would fast GUP prevent prefaulting "behind"?
> > E.g. is that effectively a limitation of the underlying backing store you're
> > using, a fundamental limitation somewhere in mm/, or a limitation in KVM itself?
> 
> I didn't explain myself properly, sorry.
> 
> What I had in mind is that kvm_mmu_auto_prefault() returns on the first
> kvm_tdp_page_prefault() failure, and starts from the ALIGN_DOWN'd window start
> rather than from the faulting page.  So if a hole is below the faulting page,
> the resident pages above it don't get prefetched either.
> 
> E.g. faulting at page 5, window [0..7].  If [4..7] are resident and [0..3] are
> UFFD-missing, the loop fails on page 0 and nothing gets prefetched, even though
> 6 and 7 are right there.
> 
> It doesn't matter when nr_pages matches the UFFD chunk size and alignment, but
> it would with smaller chunks or a non-linear access pattern.

Oh, that's easy enough to "fix", the only question is whether or not that would
be a net positive.

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 08b6a90c7131..61cae6f1d9a9 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -5179,8 +5179,7 @@ static void kvm_mmu_auto_prefault(struct kvm_vcpu *vcpu, gpa_t start,
 		if (gpa < start || gpa_to_gfn(gpa) > kvm_mmu_max_gfn())
 			return;
 
-		if (kvm_tdp_page_prefault(vcpu, gpa, error_code, KVM_PREFETCH_AUTO, &level))
-			return;
+		kvm_tdp_page_prefault(vcpu, gpa, error_code, KVM_PREFETCH_AUTO, &level);
 	}
 }

I generally don't like heuristics, but they're practically unavoidable when it
comes to stuff like this, so the other option would be to set a threshold for
when to bail.  Failure should be cheap?  So we could set the threshold to be the
default PTE_PREFETCH_NUM, that way the default behavior is that KVM agressively
tries to prefault everything.

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 08b6a90c7131..5dc820a32f8c 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -5156,8 +5156,8 @@ static void kvm_mmu_auto_prefault(struct kvm_vcpu *vcpu, gpa_t start,
 				  u64 error_code, u8 level)
 {
 	gfn_t nr_pages = READ_ONCE(auto_prefault_nr_pages);
+	gfn_t i, nr_failures;
 	int nr_pages_msb;
-	gfn_t i;
 
 	if (error_code & (PFERR_RSVD_MASK | PFERR_PRESENT_MASK))
 		return;
@@ -5179,7 +5179,10 @@ static void kvm_mmu_auto_prefault(struct kvm_vcpu *vcpu, gpa_t start,
 		if (gpa < start || gpa_to_gfn(gpa) > kvm_mmu_max_gfn())
 			return;
 
-		if (kvm_tdp_page_prefault(vcpu, gpa, error_code, KVM_PREFETCH_AUTO, &level))
+		if (!kvm_tdp_page_prefault(vcpu, gpa, error_code, KVM_PREFETCH_AUTO, &level))
+			continue;
+
+		if (++nr_failures > PTE_PREFETCH_NUM)
 			return;
 	}
 }

> FOLL_NOFAULT is fine by me; it just makes "hole" mean "not mapped" rather than
> "not resident", so slightly more cases hit this.

  reply	other threads:[~2026-10-30 19:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 20:26 [PATCH 0/4] KVM: x86/mmu: Add auto-prefetch to the TDP MMU Sean Christopherson
2026-10-28 20:26 ` [PATCH 1/4] KVM: x86/mmu: Rework gfn_to_memslot_dirty_bitmap() into auto-prefetch helper Sean Christopherson
2026-10-28 20:26 ` [PATCH 2/4] KVM: x86/mmu: Differentiate between manual and automatic prefetching Sean Christopherson
2026-10-28 20:26 ` [PATCH 3/4] KVM: x86/mmu: Add automatic prefaulting/prefetching for TDP MMU faults Sean Christopherson
2026-10-28 20:58   ` sashiko-bot
2026-10-28 21:51   ` James Houghton
2026-10-29 18:21     ` Marangoni, Marco
2026-10-29 21:09       ` Sean Christopherson
2026-10-30 13:29         ` Marangoni, Marco
2026-10-30 19:02           ` Sean Christopherson [this message]
2026-10-28 20:26 ` [PATCH 4/4] KVM: x86/mmu: Use the generic auto-prefaulting to do prefetch for direct MMUs Sean Christopherson
2026-10-28 20:54   ` sashiko-bot

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=auTp2Yp2qtqtiPkX@google.com \
    --to=seanjc@google.com \
    --cc=cc-open-source@amazon.com \
    --cc=jthoughton@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mamarang@amazon.com \
    --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