Re: [RFC PATCH v2 15/25] KVM: nSVM: Call nested_svm_transition_tlb_flush() on every VMCB switch

[Sean Christopherson]

On Tue, Jun 16, 2026, Yosry Ahmed wrote:
> Move the calls to nested_svm_transition_tlb_flush() in different
> transition code paths to svm_switch_vmcb(). This ensures that TLB
> flushes are not missed during switches, and makes it clearer that the
> TLB flushes are directly related to the active VMCB.
> 
> The ordering currently doesn't matter, but as more TLB handling is added
> for nested, requesting the TLB flushes *after* the VMCB switch will
> become a requirement.
> 
> No functional change intended (for now).
> 
> Signed-off-by: Yosry Ahmed <yosry@xxxxxxxxxx>
> ---
>  arch/x86/kvm/svm/nested.c | 10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> index 24a52aefe94ee..9a917d057aa8e 100644
> --- a/arch/x86/kvm/svm/nested.c
> +++ b/arch/x86/kvm/svm/nested.c
> @@ -707,8 +707,12 @@ static void nested_svm_transition_tlb_flush(struct kvm_vcpu *vcpu)
>  
>  static void svm_switch_vmcb(struct vcpu_svm *svm, struct kvm_vmcb_info *target_vmcb)
>  {
> +	struct kvm_vcpu *vcpu = &svm->vcpu;
> +
>  	svm->current_vmcb = target_vmcb;
>  	svm->vmcb = target_vmcb->ptr;
> +
> +	nested_svm_transition_tlb_flush(vcpu);

I'm not convinced this is the right place to do the flushing.  Yes, manually
doing the flushes requires more code, and arguably makes KVM less robust, but
IMO there's value in mimicking architectural flows because it's the architecture
that dictates the flushing.