From: Sean Christopherson <seanjc@google.com>
To: David Kaplan <David.Kaplan@amd.com>
Cc: kvm list <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Thomas Lendacky <Thomas.Lendacky@amd.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: Bug with nested PAUSE intercept on SVM
Date: Tue, 7 Apr 2026 11:24:54 -0700 [thread overview]
Message-ID: <adVL9nqJhJwvu1QO@google.com> (raw)
In-Reply-To: <DS7PR12MB820101CABFA34E85442EA256945AA@DS7PR12MB8201.namprd12.prod.outlook.com>
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@google.com
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.
next prev parent reply other threads:[~2026-04-07 18:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 18:11 Bug with nested PAUSE intercept on SVM Kaplan, David
2026-04-07 18:24 ` Sean Christopherson [this message]
2026-04-07 18:30 ` Kaplan, David
2026-05-07 21:50 ` Kaplan, David
2026-05-08 16:33 ` Sean Christopherson
2026-05-08 19:31 ` Kaplan, David
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adVL9nqJhJwvu1QO@google.com \
--to=seanjc@google.com \
--cc=David.Kaplan@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.