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

[Yosry Ahmed]

On Mon, Jul 27, 2026 at 6:19 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxx>
> > 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@xxxxxxxxxx/.
>
> Yeah, I need to get Paolo's eyeballs on those changes.

It's really none of my business, but what about just getting patch 1
merged for now? I think this is everything Sashiko needs and the tree
is already documented in the maintainer profile (so it's nothing new)?