On 5/8/26 23:33, Sean Christopherson wrote:
> Never use L0's (KVM's) PAUSE loop exiting controls while L2 is running,
> and instead always configure vmcb02 according to L1's exact capabilities
> and desires.

Queued, thanks.  While I didn't go as far as splitting in two commits,
I did apply a more or less cosmetic tweak to the WARNs.  Calling
grow_ple_window/shrink_ple_window with PLE disabled is harmless but
also makes little sense.  This can be represented by a WARN that
does not have an early return.

The WARN condition is obviously false for shrink_ple_window and
a little less obviously so for grow_ple_window, but in case any
other callers are added it can be useful to have it as a heads up.

Paolo

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index ac21f402c1ca..e02a38da5296 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -913,12 +913,15 @@ static void grow_ple_window(struct kvm_vcpu *vcpu)
 	struct vmcb_control_area *control = &svm->vmcb->control;
 	int old = control->pause_filter_count;

+	/* Adjusting pause_filter_count makes no sense if PLE is disabled.  */
+	WARN_ON_ONCE(kvm_pause_in_guest(vcpu->kvm));
+
 	/*
 	 * While running L2, KVM should intercept PAUSE if and only if L1 wants
 	 * to intercept PAUSE, and L1's intercept should take priority, i.e.
 	 * KVM should never handle a PAUSE intercept from L2.
 	 */
-	if (WARN_ON_ONCE(is_guest_mode(vcpu) || kvm_pause_in_guest(vcpu->kvm)))
+	if (WARN_ON_ONCE(is_guest_mode(vcpu)))
 		return;

 	control->pause_filter_count = __grow_ple_window(old,
(1/2) Stage this hunk [y,n,q,a,d,k,K,j,J,g,/,s,e,p,P,?]? y
@@ -939,6 +942,9 @@ static void shrink_ple_window(struct kvm_vcpu *vcpu)
 	struct vmcb_control_area *control = &svm->vmcb->control;
 	int old = control->pause_filter_count;

+	/* Adjusting pause_filter_count makes no sense if PLE is disabled.  */
+	WARN_ON_ONCE(kvm_pause_in_guest(vcpu->kvm));
+
 	if (is_guest_mode(vcpu))
 		return;