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.
next prev parent 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