Re: [PATCH v2 20/20] KVM: x86: Use gfn_to_pfn_cache for record_steal_time

On Mon, 2026-06-08 at 17:45 -0700, Sean Christopherson wrote:
> On Tue, Jun 02, 2026, David Woodhouse wrote:
> > On Sat, 30 May 2026 06:19:32 +0000, [email protected] wrote:
> > > [Severity: High]
> > > Does this introduce a scheduling while atomic bug on non-PREEMPT_RT kernels?
> > > 
> > > The CLASS(gpc_map_local, st_map) macro acquires a read_lock on gpc->lock,
> > > which disables preemption. While this lock is held, if the guest supports
> > > PV TLB flush, the code calls kvm_vcpu_flush_tlb_guest().
> > > 
> > > If TDP is disabled (shadow paging), kvm_vcpu_flush_tlb_guest() calls
> > > kvm_mmu_sync_roots() and eventually mmu_sync_children(). This path can yield
> > > via cond_resched_rwlock_write(). Yielding while preemption is disabled by
> > > the gpc read lock will trigger a BUG.
> > 
> > Ah, that issue exists in the previous versions too, but it's simple
> > enough to fix. There's no particular timing constraint for flushing the
> > TLB; it just have to be done before this vCPU ever runs again. It can
> > just be moved to the end of the function after the lock is dropped.
> > 
> > That does mean record_steal_time() should use the explicit
> > gpc_map_local_lock()/gpc_map_local_unlock() instead of the CLASS()
> > macro, but that's easy enough.
> 
> Actually, we use KVM_REQ_TLB_FLUSH_GUEST and "optimize" the code for the rare
> case where KVM already have a TLB flushed queued for the vCPU.  E.g. over two
> patches (so that changing the order of the request processing is isolated):

D'oh! Missed this when preparing the RCU-based v3, and Sashiko had to
point it out again. (And I'm fairly sure most of the rest of the
Sashiko feedback rings a bell too).

Fixing...