Re: [PATCH v1 00/28] KVM: nSVM: Optimize nSVM TLB flushes

[Sean Christopherson <seanjc@google.com>]

On Mon, Jul 27, 2026, Yosry Ahmed wrote:
> > Yosry Ahmed (28):
> >   KVM: nSVM: Flush the TLB after forcefully leaving nested
> >   KVM: SVM: Document number of ASIDs CPUID setting
> >   KVM: VMX: Generalize VPID allocation to be vendor-neutral
> >   KVM: x86/mmu: Support specifying reserved TLB tags
> >   KVM: SVM: Add helpers to set/clear ASID flush in VMCB
> >   KVM: SVM: Fallback to flush everything if FLUSHBYASID is not available
> >   KVM: SVM: Duplicate pre-run ASID check for SEV and non-SEV guests
> >   KVM: SEV: Do ASID initialization at VMCB initialization
> >   KVM: SEV: Expose sev_get_asid() outside of sev.c
> >   KVM: SVM: Use a static ASID per vCPU
> >   KVM: SVM: Only flush the fallback ASID when used by a different vCPU
> >   KVM: nSVM: Add a placeholder ASID for L2
> >   KVM: x86: hyper-v: Rename kvm_hv_vcpu_purge_flush_tlb()
> >   KVM: x86: hyper-v: Allow puring all TLB flush FIFOs
> >   KVM: nSVM: Drop svm->nested.initialized
> >   KVM: nSVM: Flush both L1 and L2 ASIDs on KVM_REQ_TLB_FLUSH
> >   KVM: nSVM: Always switch VMCB before leaving guest mode
> >   KVM: nSVM: Split nested_svm_transition_tlb_flush() into entry/exit fns
> >   KVM: nSVM: Service local TLB flushes before nested transitions
> >   KVM: nSVM: Handle nested TLB flush requests through TLB_CONTROL
> >   KVM: nSVM: Flush the TLB if L1 changes L2's ASID in vmcb12
> >   KVM: nSVM: Do not reset TLB_CONTROL in vmcb02 on nested VM-Enter
> >   KVM: x86/mmu: Rename __kvm_mmu_invalidate_addr() to
> >     kvm_mmu_sync_addr()
> >   KVM: x86/mmu: Refactor kvm_mmu_invlpg() to allow skipping the GVA
> >     flush
> >   KVM: nSVM: Flush L2's ASID when emulating INVLPGA
> >   KVM: nSVM: Flush the ASID on nested transitions if shared by L1 and L2
> >   KVM: nSVM: Use different ASIDs for L1 and L2
> >   KVM: selftests: Add a test for nested TLB flushes
> 
> Sashiko wasn't able to apply the patches:
> https://sashiko.dev/#/patchset/20260728003557.1136583-1-yosry%40kernel.org.
> 
> For some reason, it failed to apply on the baseline commit,
> 271255273d5ff348fe29d89fe4712b2f7f7907c3.
> 
> This is the top of kvm-x86/next tho, so I am not sure what went wrong:
> 
> $ git show upstream/kvm-x86/next
> commit 271255273d5ff348fe29d89fe4712b2f7f7907c3 (tag:
> kvm-x86-next-2026.07.27, upstream/kvm-x86/next, upstream/kvm-x86/HEAD)
> Merge: a204badd8432f 2abcdf03fda13 9c66085e6dcfb db3a46e200df2
> 2708ecca4dbdb 710b3a30f407e e428f9779a437 653857a5af462 ec9a16c6aeba8
> 05a0b701d1089
> Author: Sean Christopherson <seanjc@google.com>
> Date:   Mon Jul 27 12:44:28 2026 -0700
> ...
> 
> The commit was from earlier today, maybe Sashiko only fetches the
> trees every once in a while?
> 
> kvm-x86/next is not among the list of branches it tried. I don't see
> the tree in MAINTAINERS, so perhaps this patch was never picked up:
> https://lore.kernel.org/kvm/20260428171541.1342335-2-seanjc@google.com/.

Yeah, I need to get Paolo's eyeballs on those changes.

> Adding Roman here just in case. Sean, let me know if you want me to
> resend this series after we figure this out.

This is probably my fault?  I force-pushed to kvm-x86/next this morning to fix a
stupid goof I made, maybe Sashiko was confused by the exact objects not being in
in linux-next?  I would say do nothing for now, we can always do a resend if us
humans don't find anything in this version to necessitate a v2.