Re: [RFC PATCH v2 22/25] KVM: x86/mmu: Refactor kvm_mmu_invlpg() to allow skipping the gva flush

[Sean Christopherson <seanjc@google.com>]

On Mon, Jul 27, 2026, Yosry Ahmed wrote:
> On Mon, Jul 27, 2026 at 8:38 AM Sean Christopherson <seanjc@google.com> wrote:
> > On Fri, Jul 24, 2026, Yosry Ahmed wrote:
> > > > > What's the main objection to kvm_mmu_invalidate_addr_in_root()?
> > > >
> > > > I don't love the __kvm_mmu_invalidate_addr() => kvm_mmu_invalidate_addr_in_root()
> > > > callchain.  It's not at all obvious that the in_root() helper shouldn't be called
> > > > directly.  I don't hate it, but I do think we need better clarity on what all this
> > > > is doing.
> > > >
> > > > E.g. when looking at __kvm_inject_emulated_page_fault(), since it hardcodes a
> > > > single root, it's a bit headscratching to use kvm_mmu_invalidate_addr() instead
> > > > of kvm_mmu_invalidate_addr_in_root.
> > >
> > > Coming back to this, I agree it's confusing. I think this can be fixed
> > > with a better name though. Looking at
> > > kvm_mmu_invalidate_addr_in_root() (or __kvm_mmu_invalidate_addr() in
> > > current code), seems like what it does is find SPTEs for that address,
> > > sync them, and flush the TLB if needed.
> > >
> > > So maybe mmu_sync_addr_sptes() or mmu_sync_and_flush_addr_sptes()?
> >
> > kvm_mmu_sync_addr()?  The "sptes" part is implied in things like kvm_sync_page()
> > and mmu_sync_children().
> 
> Sounds good. I assume you're okay with keeping everything else the
> same way? I assume you didn't like any of the alternatives?

Ya, I don't want risk delaying this series chasing down flaws that no one cares
about in practice.