Re: [PATCH v3 11/27] KVM: SVM: Only flush the fallback ASID when used by a different vCPU

From: Yosry Ahmed

Date: Thu Oct 15 2026 - 18:03:53 EST


On Thu, Oct 15, 2026 at 2:44 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> On Mon, Oct 12, 2026 at 4:36 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> >
> > Instead of always flushing the fallback ASID on every vCPU run, only
> > flush it if the last vCPU that used it on the pCPU changes. This avoids
> > constant TLB flushing on a vCPU using the fallback ASID if no other
> > vCPUs that use the same ASID ran on the same pCPU.
> >
> > Note that checking (and flushing) the current ASID on vCPU load is not
> > sufficient, as it is possible that a vCPU is using the fallback ASID
> > only for L1 or only for L2. To do this correctly on vCPU load, both L1
> > and L2 ASIDs would need to be checked, and the respective VMCB would
> > need to be flushed. This would not be much simpler, and would perform
> > unnecessary flushes in some cases (e.g. loading a vCPU that uses the
> > fallback ASID for L2, but L2 doesn't actually run until the vCPU is
> > unloaded).
> >
> > Another alternative is always flushing on vCPU load if the current ASID
> > is the fallback ASID, and flushing on nested transitions if the new ASID
> > is the fallback ASID. Again, this is not much simpler and also incurs
> > unnecessary flushes in some cases.
> >
> > Do the logical thing and track the vCPU using the fallback ASID instead.
>
> Wouldn't it be simpler to track the VMCB associated with the fallback
> ASID on each pCPU? Then, you avoid any confusion regarding whether L1,
> L2, or both have been assigned the fallback ASID.

It would be if we went with checking the ASID on vCPU and nested
transitions. But since we're checking in pre_svm_run(), I don't think
it simplifies things. Oh, I guess it doesn't simplify this specific
patch, but we don't need to check if both L1 and L2 use the fallback
ASID on nested transitions.. but we have to check if they both use the
same ASID anyway for SEV.

OTOH, it would make cleanup more complicated, as we'd need to do it in
both vCPU freeing and nested freeing.

Did I miss something?