Re: [PATCH v3 26/27] KVM: nSVM: Use different ASIDs for L1 and L2

[Sean Christopherson]

On Mon, Oct 19, 2026, Yosry Ahmed wrote:
> On Mon, Oct 19, 2026 at 11:50 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
> >
> > On Fri, Oct 16, 2026 at 5:25 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > >
> > > On Fri, Oct 16, 2026 at 02:17:30PM -0700, Jim Mattson wrote:
> > > > On Mon, Oct 12, 2026 at 4:37 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > > > >
> > [ ... ]
> > > > Per the APM, volume 2, Section 15.16.1, "TLB Flush":
> > > >
> > > > > All TLB entries belonging to all ASIDs are flushed by SMI, RSM, MTRR modifications, IORR modifications, and access to other system MSRs that affect address translation.
> > > >
> > > > With two separate ASIDs and the unconditional flush removed, do we
> > > > flush both ASIDs in the above instances?
> > >
> > > SMI and RSM, yeah I think so. kvm_smm_changed() ->
> > > kvm_mmu_reset_context() deletes all roots, and kvm_mmu_load() will flush

s/deletes/unloads, because the roots themselves are almost always still reachable
through the hashed list of shadow pages.

> > > the current ASID when a new root is loaded.
> >
> > Okay. Is this mechanism obvious to those who are versed in the ways of
> > the KVM MMU?
> 
> I don't consider myself versed in the ways of the KVM MMU, it took me
> a few minutes to track this done, so I think it's okay.

No, it's not ok, though it's also not something that needs to be addressed in
this series.  Historically, KVM relied on kvm_mmu_reset_context() to perform TLB
flushes basically everywhere, e.g. on CR0 and CR4 writes.  It was a nightmare
on multiple fronts, e.g. it was suboptimal when toggling bits that needed a TLB
flush but not a full MMU rebuild, and understanding whether KVM was deliberately
doing TLB flushes or not was difficult, which in turn made trying to optimize
any of that code very painful because it meant disentangling years of KVM code
*and* pouring over the SDM and APM to make sure we got the TLB flushes right.

In short, the fact that kvm_mmu_reset_context() happens to guarantee a TLB flush
of the new/current root is a side effect and an implementation detail.  If a TLB
flush (for the guest) is architecturally required, then KVM should emulate that
exact requirement, even if it means queueing up what will be redundant flushes.
That makes it easier for newcomers to follow the code, and gives us more freedom
to tweak and optimize MMU context changes/resets.

Concretely:

  Author:     Paolo Bonzini <pbonzini@xxxxxxxxxx>
  AuthorDate: Mon Feb 14 11:50:36 2022 -0500
  Commit:     Paolo Bonzini <pbonzini@xxxxxxxxxx>
  CommitDate: Tue Mar 1 08:50:42 2022 -0500

    KVM: x86: flush TLB separately from MMU reset
    
    For both CR0 and CR4, disassociate the TLB flush logic from the
    MMU role logic.  Instead  of relying on kvm_mmu_reset_context() being
    a superset of various TLB flushes (which is not necessarily going to
    be the case in the future), always call it if the role changes
    but also set the various TLB flush requests according to what is
    in the manual.

For SVM, the redundant flushes are a complete non-issue.  It's basically an extra
memory write.

For VMX, the INVVPID isn't free, but for emulated SMM I can't imagine it's a
meaningful performance issue.  And FWIW, the only reason not doing
KVM_REQ_TLB_FLUSH_GUEST isn't a bug is because hardware isn't allowed to cache
linear mappings when EPT is in used (and INVEPT invalidates both guest-physical
and combined mappings).