Re: KVM: x86/mmu: __kvm_rmap_lock() preemption assert trips on PREEMPT_RT

[Sean Christopherson <seanjc@google.com>]

On Fri, Aug 28, 2026, David Woodhouse wrote:
> On Fri, 2026-08-28 at 12:45 +0200, Sebastian Andrzej Siewior wrote:
> > On 2026-08-27 15:17:57 [-0700], Sean Christopherson wrote:
> > > > @@ -1745,11 +1754,15 @@ static bool kvm_rmap_age_gfn_range(struct kvm *kvm,
> > > >  	gfn_t gfn;
> > > >  	int level;
> > > >  
> > > > +#ifdef CONFIG_PREEMPT_RT
> > > > +	guard(read_lock)(&kvm->mmu_lock);
> > > > +#endif
> > > 
> > > And now I remember why I swept this under the rug.  This really should take
> > > mmu_lock for write, otherwise concurrent aging threads could theoretically get
> > > stuck competing for KVM_RMAP_LOCKED.  Which is silly, because they don't actually
> > > need to take a lock of any kind.  I.e. it's not super trivial?
> > > 
> > > Wait, duh.  It is trivial if mmu_lock is held, because then KVM can operate on
> > > rmaps without any KVM_RMAP_LOCKED shenanigans.  I wouldn't test this because it
> > > might break horribly, but I think this?
> > 
> > So you drop the bit spinlock and rely on kvm->mmu_lock instead?

Ya, it's basically a revert of the per-rmap locking, but just for PREEMPT_RT.

> > No sure why it should break horribly but it looks reasonable.

I wasn't worried about the locking, I was worried I was forgetting an rmap detail,
e.g. I almost forgot to update rmap_head->val in the "unlock" path.

> FWIW it survived the night in my GPC invalidation torture tests.

Awesome!  I'll throw a PREEMPT_RT kernel through the normal testing and hopefully
get a patch posted today.