Re: [GIT PULL] KVM (mostly s390) fixes for Linux 7.2-rc7

+Yosry

On Fri, Aug 07, 2026, Paolo Bonzini wrote:
> - disable use of INVLPGA when NPT is enabled, because it doesn't seem
>   to flush TLBs correctly

...

> Paolo Bonzini (3):
>       KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled

Why did this get rushed in?  There was quite a bit of discussion, both on the
code itself[1][2] and on the assessment that this appears to be hardware issue[3].
IMO, neither of those discussions was resolved enough to merge the patch as-is.

I can appreciate wanting to get a fix into stable ASAP, but we could have gone
with a *much* simpler fix for stable@.  The bulk of this change is a performance
optimization masquerading as a bug fix, and I'm not convinced it's actually
optimizing anything meaningful, because SVM only queues the TLB flush, and that
is super cheap.  E.g. the "we don't know why this is failing, let's smack it with
a hammer" patch could have been:

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 3057ca7051db..58bc4a1cb7a4 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4237,7 +4237,15 @@ static void svm_flush_tlb_gva(struct kvm_vcpu *vcpu, gva_t gva)
 {
        struct vcpu_svm *svm = to_svm(vcpu);
 
-       invlpga(gva, svm->vmcb->control.asid);
+       if (!npt_enabled) {
+               invlpga(gva, svm->vmcb->control.asid);
+               return;
+       }
+
+       if (static_cpu_has(X86_FEATURE_FLUSHBYASID))
+               svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ASID;
+       else
+               svm->current_vmcb->asid_generation--;
 }
 
 static void svm_flush_tlb_guest(struct kvm_vcpu *vcpu)

I don't care _that_ much about the code itself, though I still think the out-param
is all kinds of ugly.  What frustrates me most is completely ignoring the processes
that everyone else is trying quite hard to follow.  I'm a-ok with getting overruled
on jugdment calls and matters of taste, but I'm not at all ok with doing so silently
and without what I would consider an honest attempt to address review feedback.

[1] https://lore.kernel.org/all/[email protected]
[2] https://lore.kernel.org/all/CAO9r8zM=Mb=eTEFGF0G-POvwwbSr7e8SN6zcDp=GstzKtBKcow@mail.gmail.com
[3] https://lore.kernel.org/all/CAO9r8zMopB=YKXs5pkQmPf9uHKE0P0XORcNbc60AWXTusuY3tg@mail.gmail.com