Re: [PATCH v3 22/27] KVM: nSVM: Flush the TLB if L1 changes L2's ASID in vmcb12

[Jim Mattson]

On Thu, Oct 15, 2026 at 4:56 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> > > > > @@ -691,23 +689,35 @@ static void nested_save_pending_event_to_vmcb12(struct vcpu_svm *svm,
> > > > >  static void nested_svm_entry_tlb_flush(struct kvm_vcpu *vcpu)
> > > > >  {
> > > > >         struct vcpu_svm *svm = to_svm(vcpu);
> > > > > +       bool new_asid = false;
> > > > >
> > > > >         /* Handle pending Hyper-V TLB flush requests */
> > > > >         kvm_hv_nested_transtion_tlb_flush(vcpu, npt_enabled);
> > > > >
> > > > > +       if (svm->nested.ctl.asid != svm->nested.last_asid) {
> > > > > +               svm->nested.last_asid = svm->nested.ctl.asid;
> > > > > +               new_asid = true;
> > > > > +       }
> > > >
> > > > To make sure we don't miss a flush after restore, do we need to clear
> > > > last_asid in svm_set_nested_state()?
> > >
> > > In [1], we set svm->nested.vmcb02.cpu = -1 in svm_allocate_nested(),
> > > which should be called when EFER.SVME is set on restore, and should
> > > force a TLB flush on the first vCPU run. That being said, if EFER.SVME
> > > was already set (not a fresh vCPU), we won't necessarily flush the
> > > TLB. KVM_SET_SREGS will _probably_ flush the TLB, but I don't think
> > > it's guaranteed.
> >
> > I'm pretty sure that restoring nested state on an existing vCPU with
> > the same asid12 and no TLB_CONTROL skips the flush.
>
> I can clear last_asid in svm_set_nested_state() to make sure we don't
> break this.
>
> >
> > > But wouldn't this also affect non-nested? Are we guaranteed to flush
> > > L1's ASID after restore?
> >
> > That may be a bug too.
>
> It's tricky. KVM_SET_SREGS will only flush (with 64-bit vCPUs) if
> CR0/CR3/CR4/EFER are changed apparently. But it's not just the TLB
> flush, the entire MMU context wouldn't be reset?
>
> I am not sure if there is a practical use case for restoring on an
> existing vCPU tho.

KVM APIs make me want to kill myself.