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

[Yosry Ahmed]

> > > > @@ -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.