Re: [PATCH v2 01/20] locking/rt: Use raw_spin_lock_irqsave() in __rwbase_read_unlock()

[Peter Zijlstra <peterz@infradead.org>]

On Sat, May 30, 2026 at 01:47:06PM +0100, David Woodhouse wrote:
> On Sat, 2026-05-30 at 12:26 +0200, Paolo Bonzini wrote:
> > 
> > Yeah, I think so.
> > 
> > The write side needs kvm->srcu so it would have to be yet another SRCU. 
> > I initially thought that sucks for the code that calls kvm_gpc_check(), 
> > but maybe not because it simply replaces read_lock/read_unlock.
> > 
> > By using a seqcount for the data, SRCU only needs to be synchronized in 
> > gpc_unmap().  So, something like this:
> 
> It isn't just gpc_unmap() which does the invalidation. We also
> invalidate from the MMU notifier in gfn_to_pfn_cache_invalidate_start()
> which would also have to synchronize, wouldn't it?

Ok, so I had a look at what this code actually does, and it appears to
be a guest frame number to page frame number cache, managed by
mmu_notifiers.

IOW, its some software TLB thing (pre HVM Xen support?)

Now, mmu_notifier_invalidate_range_start() has a rather explicit
might_sleep() in, and while there is an
mmu_notifier_invalidate_range_start_noblock(), that has an error return,
and it is clearly specified that if that thing returns non-zero, PTEs
must not be changed.

With all that, I don't see why we can't block for srcu_synchronize() in
gfn_to_pfn_cache_invalidate_start().

Now, I've never much looked at mmu_notifiers, but for native, TLBI might
require sending IPIs to all CPUs, and as such cannot happen in atomic
sections. I would expect this same to extend to mmu_notifiers. It must
be possible to sleep in them.

What am I missing?