Message-ID: <aNZH+ftDGaHA7qCT@yzhao56-desk.sh.intel.com>
Date: Fri, 26 Sep 2025 15:59:53 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini
	<pbonzini@...hat.com>, <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] KVM: selftests: Test prefault memory during
 concurrent memslot removal

On Fri, Sep 26, 2025 at 11:08:38AM +0800, Yan Zhao wrote:
> Thank you, Sean!
> It looks good to me.
> Testing passed on my side.
> 
> On Wed, Sep 24, 2025 at 10:42:55AM -0700, Sean Christopherson wrote:
> > From: Yan Zhao <yan.y.zhao@...el.com>
> > 
> > Expand the prefault memory selftest to add a regression test for a KVM bug
> > where TDX's retry logic (to avoid tripping the zero-step mitigation) would
> > result in deadlock due to the memslot deletion waiting on prefaulting to
> > release SRCU, and prefaulting waiting on the memslot to fully disappear
Nit: it's not for the bug of "TDX's retry logic" (we have a separate TDX
selftest from Reinette for that one).

This selftest is for the KVM bug for generic VMs and TDs, where the SRCU lock is
held in kvm_vcpu_pre_fault_memory(). Previously, prefetching an invalid memslot
caused kvm_tdp_map_page() to retry on RET_PF_RETRY endlessly, preventing the
SRCU lock from being released.

> > (KVM uses a two-step process to delete memslots, and KVM x86 retries page
> > faults if a to-be-deleted, a.k.a. INVALID, memslot is encountered).
> > 
> > To exercise concurrent memslot remove, spawn a second thread to initiate
> > memslot removal at roughly the same time as prefaulting.  Test memslot
> > removal for all testcases, i.e. don't limit concurrent removal to only the
> > success case.  There are essentially three prefault scenarios (so far)
> > that are of interest:
> > 
> >  1. Success
> >  2. ENOENT due to no memslot
> >  3. EAGAIN due to INVALID memslot
> > 
> > For all intents and purposes, #1 and #2 are mutually exclusive, or rather,
> > easier to test via separate testcases since writing to non-existent memory
> > is trivial.  But for #3, making it mutually exclusive with #1 _or_ #2 is
> > actually more complex than testing memslot removal for all scenarios.  The
> > only requirement to let memslot removal coexist with other scenarios is a
> > way to guarantee a stable result, e.g. that the "no memslot" test observes
> > ENOENT, not EAGAIN, for the final checks.
> > 
> > So, rather than make memslot removal mutually exclusive with the ENOENT
> > scenario, simply restore the memslot and retry prefaulting.  For the "no
> > memslot" case, KVM_PRE_FAULT_MEMORY should be idempotent, i.e. should
> > always fail with ENOENT regardless of how many times userspace attempts
> > prefaulting.
> > 
> > Pass in both the base GPA and the offset (instead of the "full" GPA) so
> > that the worker can recreate the memslot.
> > 
> > Signed-off-by: Yan Zhao <yan.y.zhao@...el.com>
> > Co-developed-by: Sean Christopherson <seanjc@...gle.com>
> > Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> > ---
> > 
> > v3 of Yan's series to fix a deadlock when prefaulting memory for a TDX
> > guest.  The KVM fixes have already been applied, all that remains is this
So it's for generic and TDX guests.

> > selftest.
> > 
> > v3: Test memslot removal for both positive and negative testcases, and simply
> >     ensure a stable result by restoring the memslot and retrying if necessary.
> > 
> > v2: https://lore.kernel.org/all/20250822070305.26427-1-yan.y.zhao@intel.com
> > 
> >  .../selftests/kvm/pre_fault_memory_test.c     | 131 +++++++++++++++---
> >  1 file changed, 114 insertions(+), 17 deletions(-)

Powered by blists - more mailing lists