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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

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? No sure
> why it should break horribly but it looks reasonable.

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

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]