Re: [PATCH v3 3/7] KVM: pfncache: Use RCU for readers instead of a rwlock

[Sean Christopherson <seanjc@google.com>]

On Thu, Aug 06, 2026, David Woodhouse wrote:
> On Thu, 2026-08-06 at 09:53 -0700, Sean Christopherson wrote:
> > On Wed, Aug 05, 2026, sashiko-bot@kernel.org wrote:
> > > Replace the per-cache rwlock with RCU for the read side.
> > 
> > I don't hate the idea, but I am very against using RCU.  Unless it's "impossible",
> > e.g. because synchronize_srcu() allocates memory and breaks OOM kill, I would
> > strongly prefer to use SRCU, probably with a dedicated kvm->gpc_srcu, so that
> > synchronization doesn't need to wait on all CPUs in the system.  The tail latencies
> > for synchronize_rcu() are horrendous, especially for many-CPU systems.  If it
> > were only mmu_notifiers that got hit, it miiiight be acceptable, but since this
> > will affect vCPU tasks in the refresh() path as well, normal RCU is pretty much
> > a non-starter.
> 
> Yeah, the refresh() path got pretty slow in my first attempt, before
> optimising that *not* to have a grace period if the memslot generation
> changed but the actual GPA→uHVA (and memslot) don't *change*.
> 
> > Even SRCU could be problematic: if synchronize_srcu_expedited() is forced to wait,
> > the wait time can easily get to 20+ milliseconds, which again is a non-starter for
> > things like steal-time updates and nVMX pages.
> 
> But we don't have to synchronize from the read side. The code path
> which will do so most often is gfn_to_pfn_cache_invalidate_start(). And
> the refresh() path which is already the fallback slow path which can sleep.

It's probably a slow path for all current users, but it definitely won't be a slow
path for nested virtualization, because a refresh() will be required any time the
GPA changes, i.e. any time the vCPU runs a different vmc{b,c}12.  That's why I
think we should treat GPCs that are strictly bound to a vCPU differently.