Re: [PATCH v3 1/9] perf/x86/intel: Ensure guest PEBS path doesn't set unwanted PERF_GLOBAL_CTRL bits

Sean Christopherson <[email protected]> Thu, 21 May 2026 07:04:41 -0700
Newsgroups dev.linux.lists.sashiko,org.kernel.vger.linux-perf-users
Message-ID <[email protected]>
On Thu, May 21, 2026, Dapeng Mi wrote:
> On 5/15/2026 9:49 AM, Mi, Dapeng wrote:
> > On 5/15/2026 8:01 AM, Sean Christopherson wrote:
> >>> Anyway, we could optimize the code further like below and thoroughly filter
> >>> away these extra bits. (only building, not test on real HW)
> >> Hmm, I think I'd rather figure out what it would take to drop the FIXME entirely.
> >> And if we need to keep the check, I'm a-ok risking false positives until we have
> >> a better understanding of why the check exists.
> > Kan Liang should be the best man who knows the history, but he has left
> > Intel. I would check this with other guys internally and look at if they
> > know the reason.
> 
> Just checked the commit history, It looks the reason of disabling guest
> PEBS here is to avoid breaking the host !exclude_guest PEBS event sampling.
> Host may create !exclude_guest event to profile both root and non-root
> mode, but it's conflicted with guest PEBS sampling in non-root mode. So
> guest PEBS sampling has to be disabled if there are active host PEBS
> events. Thanks.

But that doesn't make any sense, because the host can't use PEBS to sample non-root
mode due to the DS area being virtually addressed.  It's entirely possible that
was pure oversight, given that commit 58f6217e5d01 ("perf/x86/intel: KVM: Mask
PEBS_ENABLE loaded for guest with vCPU's value.") was necessary.

But I'm still not convinced: if that _really_ was the motivation, then I would
hope that scenario was at least smoke tested, and any testing whatsoever would
have crashed the guest.

Though given how buggy this code has been, I suppose it's plausible there was
simply testing.