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

[Sean Christopherson <seanjc@google.com>]

On Thu, Oct 22, 2026, Yosry Ahmed wrote:
> On Thu, Oct 22, 2026 at 3:44 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Fri, Oct 16, 2026, Jim Mattson wrote:
> > > On Mon, Oct 12, 2026 at 4:37 PM Yosry Ahmed <yosry@kernel.org> wrote:
> > > Moreover, does this change the semantics of PV TLB flush? In
> > > record_steal_time(), we have:
> > >
> > > if (st_preempted & KVM_VCPU_FLUSH_TLB)
> > >         kvm_vcpu_flush_tlb_guest(vcpu);
> > >
> > > IIUC, an idle vCPU that wakes into L2 will flush only L2's ASID. In
> > > the past, with a shared ASID, L1's ASID was always flushed on emulated
> > > VM-exit anyway. Now, L1's ASID will be unaffected. Though I can't find
> > > any real documentation on PV TLB flush, it *seems* like the remote
> > > vCPU would want L1's ASID to be flushed. OTOH, this change makes nSVM
> > > behave just like nVMX.
> >
> > That's a bug that absolutely needs to be fixed, probably relatively urgently.  We
> > should also document that passing through the steal_time shared information to L2
> > to utilize PV TLB flushes for L2 is explicitly not supported.
> >
> > I hate to re-introduce deferred actions for L2 => L1 things, but that seems like
> > the only sane way to handle this, because handling the !tdp_enabled case, where
> > KVM needs to sync the current root, requires knowing what MMU is going to be in
> > use when L1 regains control.  Yuck.
> 
> Are you implying that *you* will be re-introducing deferred actions? :P

Heh, probably not this calendar year.