Re: [RFC PATCH 0/4] KVM: x86/mmu: don't zap secondary MMU on permission upgrade

[Sean Christopherson <seanjc@google.com>]

On Fri, Oct 30, 2026, Claudio Imbrenda wrote:
> On Fri, 30 Oct 2026 12:11:07 +0100
> Carlos López <clopez@suse.de> wrote:
> 
> [...]
> 
> > > regarding this series:
> > > 
> > > on x86 you don't care what the new permissions are, because you're
> > > updating when re-faulting (if I understood correctly).  
> > 
> > Correct.
> > 
> > > for s390 it might be beneficial to know what the new permissions are;
> > > of course we could look up the vma and find out, but since you are
> > > already checking the permissions, maybe you can find a way to also
> > > convey the new permission bits?
> > > 
> > > that would make our life on s390 easier :)  
> > 
> > Right, getting the new bits from vma->flags should be trivially done
> > from the MMU_NOTIFY_PROTECTION_VMA callsites. There'd be no users in
> > this series though.  The rest of architectures still need the notifier to
> > tell them if the change is an upgrade, since they don't have an easy way
> > to grab the old RWX bits. Passing the old RWX bits from the MMU notifier
> > does not seem trivial to me either.

But why is core MM even doing mmu_notifier_invalidate_range_{start,end}() in the
first place?  I.e. why add MMU_NOTIFIER_RANGE_PERM_UPGRADE?  Just skip the
"invalidation".