RE: Bug with nested PAUSE intercept on SVM

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Sean Christopherson <seanjc@xxxxxxxxxx>
> Sent: Tuesday, April 7, 2026 1:25 PM
> To: Kaplan, David <David.Kaplan@xxxxxxx>
> Cc: kvm list <kvm@xxxxxxxxxxxxxxx>; LKML <linux-kernel@xxxxxxxxxxxxxxx>;
> Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Lendacky, Thomas
> <Thomas.Lendacky@xxxxxxx>; Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Subject: Re: Bug with nested PAUSE intercept on SVM
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Tue, Apr 07, 2026, David Kaplan wrote:
> > Hi,
> >
> > On AMD SVM when the L1 guest is trying to intercept every PAUSE
> instruction
> > in an L2 guest, the PAUSE intercept sometimes fails to fire.  I have a theory
> > on the source of the bug and also included a short reproducer below.
> >
> > In this scenario, L1 has created a guest with the pause count and threshold
> > set to 0, and the PAUSE intercept bit set.  I *think* the bug is that if the
> > vCPU gets scheduled out on L0 while we're in the L2 guest, then upon
> resuming
> > the vCPU KVM calls shrink_ple_window() which doesn't appear to take into
> > account the fact that svm->vmcb might be for the L2 guest and not the L1.
> As
> > a result, it looks like it sets the pause count to the default (3000) causing
> > many PAUSE instructions in L2 to not be intercepted.
>
> It's probably even simpler than that: KVM is completely broken.
>
> https://lore.kernel.org/all/20250131010601.469904-1-seanjc@xxxxxxxxxx
>
> Paolo, can I finally apply that patch?  I brought it up in PUCK a while back,
> and IIRC you were resistant to dropping "support" for cpu_pm=on setups.

Interesting.  But does that patch solve my problem?  It looks like it would still call shrink_ple_window even if L2 was scheduled out and change the page_filter_count in vmcb02, if I'm reading it correctly.

--David Kaplan