Re: [Patch v3 1/8] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Mi, Dapeng]

On 6/15/2026 8:59 AM, Mi, Dapeng wrote:
> On 6/12/2026 5:46 PM, Peter Zijlstra wrote:
>> On Fri, Jun 12, 2026 at 05:01:07PM +0800, Dapeng Mi wrote:
>>> AnyThread mode deprecation is enumerated by CPUID.0AH:EDX[15] instead of
>>> PERF_CAPABILITIES MSR. It's not a good practice to define a bit to
>>> represent "anythread deprecation" in perf_capabilities. It leads to the
>>> anythread_deprecated bit could be overwritten by the real value of
>>> PERF_CAPABILITIES MSR, just like the below code in update_pmu_cap() does.
>>>
>>> ```
>>> if (!intel_pmu_broken_perf_cap()) {
>>> 	/* Perf Metric (Bit 15) and PEBS via PT (Bit 16) are hybrid enumeration */
>>> 	rdmsrq(MSR_IA32_PERF_CAPABILITIES, hybrid(pmu, intel_cap).capabilities);
>>> }
>>> ```
>>>
>>> It leads to the anythread_deprecated bit is cleared to 0 and the "any"
>>> attribute is incorrectly shown in the /sys/devices/cpu/format/ folder on
>>> these support Perfmon v6 platforms, like Clearwater Forest.
>>>
>>> ```
>>> $grep . /sys/devices/cpu/format/*
>>> /sys/devices/cpu/format/acr_mask:config2:0-63
>>> /sys/devices/cpu/format/any:config:21
>>> /sys/devices/cpu/format/cmask:config:24-31
>>> ```
>>>
>>> So remove the anythread_deprecated bit from perf_capabilities structure
>>> and directly depends on CPUID.0AH:EDX[15] to judge if anythread is
>>> deprecated.
>> Again, no markdown please. I've stripped it from these patches.
> My bad. Thanks a lot.
>
> BTW, Peter, have you pull these patches? I didn't see them in perf/core or
> perf/urgent branches. Sashiko reports a defect about "Patch 5/8:
> perf/x86/intel: Validate the return value of intel_pmu_init_hybrid()". If
> not, I would post a v4 patchset to fix the defect. Thanks.

Just found the patches are merged into the perf/core branch in peterz/queue
tree. :)

Peter, Sashiko raises below concern against the patch 5/8: "perf/x86/intel:
Validate the return value of intel_pmu_init_hybrid()",

"

[Severity: Medium]
Does moving intel_pmu_arch_lbr_init() below
intel_pmu_check_event_constraints_all() bypass the dynamic constraint
validation for branch counters?

When intel_pmu_check_event_constraints_all() runs, it eventually calls
intel_pmu_check_dyn_constr(). This check relies on the PMU_FL_BR_CNTR flag
and the x86_pmu.lbr_counters mask:

arch/x86/events/intel/core.c:intel_pmu_check_dyn_constr() {
    ...
        case DYN_CONSTR_BR_CNTR:
            if (x86_pmu.flags & PMU_FL_BR_CNTR)
                mask = x86_pmu.lbr_counters;
            break;
    ...
}

Because intel_pmu_arch_lbr_init() is now deferred until after this validation,
the PMU_FL_BR_CNTR flag hasn't been set yet. Will this cause the dynamic
constraint check for branch counters to evaluate to false and be skipped?

"

It's a true defect. We need below changes to fix the defect. Would you
prefer to post a new patchset or just a single patch to fix the defect? Thanks.

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 74dbf24b0ab6..edf6f8732234 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -8840,11 +8840,11 @@ __init int intel_pmu_init(void)
                pr_cont("AnyThread deprecated, ");
        }

-       intel_pmu_check_event_constraints_all(NULL);
-
        if (boot_cpu_has(X86_FEATURE_ARCH_LBR))
                intel_pmu_arch_lbr_init();

+       intel_pmu_check_event_constraints_all(NULL);
+
        /*
         * Access LBR MSR may cause #GP under certain circumstances.
         * Check all LBR MSR here.


>
>
>