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

[Jim Mattson]

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
> 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?

> MTRR writes seem to do nothing beyond store the value, probably since
> 0a7b73559b39 ("KVM: x86: Remove VMX support for virtualizing guest MTRR
> memtypes"). It is documented as an errata but I maybe KVM should still
> flush the TLB? If that's a real bug, it's separate from this series tho.
> We just need to make sure if we fix it, we should flush both ASIDs. We
> can probably just reset the MMU context here too?

Probably. Admittedly, it's orthogonal to this series.

> I can't find anything related to IORR in KVM.

Me neither. :)

> For MSRs, I think the relevant ones are EFER and PAT:
>
> - For EFER, a change to KVM_MMU_EFER_ROLE_BITS resets the MMU similar to
>   SMI/RSM, so covers both ASIDs. Clearing EFER.SVME frees L2's ASID and
>   re-allocating an ASID will flush it by clearing last_asid.

Okay.

> - For PAT, I am not sure if that falls under "system MSRs that affect
>   address translation", but KVM isn't flushing for L1 today on PAT
>   writes anyway, so I hope not?

Maybe not. Intel, at least, puts the burden of flushing TLBs on
software. In volume 3 of the SDM, section 14.12.4, "Programming the
PAT":

> The operating system (OS) is responsible for ensuring that changes to a PAT entry occur in a manner that maintains the consistency of the processor caches and translation lookaside buffers (TLB). It requires the OS to invalidate all affected TLB entries (including global entries) and all entries in all paging-tructure caches.

> >
> > 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.
>
> I am honestly not sure. It seems like we should be flushing the context
> that issued the PV flush. But I also suppose (aside from Hyper-V) all L2
> PV calls should go to L1, not L0, so should we always flush L1's context
> here?
>
> It would be a pre-existing bug, but this series would be adding it to
> SVM as well. Adding David here since his name appears all over the git
> log for that code, so hopefully he'll tell us for sure.

It's just happenstance that the PV TLB flush mechanism works with nSVM
today, but I don't think we should feel free to break it.