Re: [PATCH v3 19/27] KVM: nSVM: Service local TLB flushes before nested transitions
From: Jim Mattson
Date: Fri Oct 16 2026 - 15:45:34 EST
On Thu, Oct 15, 2026 at 3:35 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Thu, Oct 15, 2026 at 3:20 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
> >
> > On Mon, Oct 12, 2026 at 4:36 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > >
> > > Service pending TLB flushes for a specific context (L1 vs. L2) before
> > > entering/leaving guest mode, as KVM does not track TLB flush requests
> > > for L1 vs. L2. This is not currently required as KVM always flushes the
> > > TLB on nested transitions, but it is a requirement to drop the
> > > unconditional flushes.
> > >
> > > TLB flushes are performed through the VMCB's TLB_CONTROL field, so
> > > service the flushes before every VMCB switch (except the precautionary
> > > switch in svm_free_nested()). Servicing flushes may end up purging the
> > > relevant HV TLB flush FIFO, which is based on guest_mode, so make sure
> > > local TLB flushes are handled before calling {enter/leave}_guest_mode().
> > >
> > > This is conceptually similar to how nVMX calls
> > > kvm_service_local_tlb_flush_requests(), except that the VMX calls only
> > > have ordering requirements on {enter/leave}_guest_mode(), and not
> > > switching the VMCS, because VPID used for TLB flushes depends on
> > > guest_mode, and flushes are not VMCS-based.
> > >
> > > Note that nested_svm_{entry/exit}_tlb_flush() must be called after
> > > kvm_service_local_tlb_flush_requests(), otherwise the TLB flushes will
> > > be immediately applied on the outgoing VMCB rather than the incoming
> > > one.
> > >
> > > Signed-off-by: Yosry Ahmed <yosry@xxxxxxxxxx>
> > > ---
> > > arch/x86/kvm/svm/nested.c | 22 ++++++++++++++++++++++
> > > 1 file changed, 22 insertions(+)
> >
> > [ ... ]
> >
> > > @@ -1549,6 +1567,8 @@ void svm_leave_nested(struct kvm_vcpu *vcpu)
> > > vcpu->arch.nested_run_pending = 0;
> > > svm->nested.vmcb12_gpa = INVALID_GPA;
> > >
> > > + nested_svm_service_local_tlb_flushes(vcpu);
> > > +
> >
> > When called from svm_vcpu_free() during teardown,
> > kvm_service_local_tlb_flush_requests() will be called for a vCPU that
> > is being destroyed--and isn't loaded. By that point, the MMU has
> > already been unloaded. Is that safe?
>
> It should be, VMX already does it.
>
> I am assuming you are specifically asking about
> kvm_vcpu_flush_tlb_guest(), as it could end up syncing roots with TDP
> off. kvm_mmu_unload() should set all roots to INVALID_PAGE. Both
> kvm_mmu_sync_roots() and kvm_mmu_sync_prev_roots() will then
> gracefully skip.
I'm just paranoid about process teardown and borrowed MMs.