Re: [Patch v8 21/23] perf/x86/intel: Enable PERF_PMU_CAP_SIMD_REGS capability

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The new SIMD registers capability and mask initialization are skipped for older PEBS V4+ architectures (like Icelake, Sapphire Rapids, Alder Lake, and Raptor Lake), leaving them without support for YMM, ZMM, eGPRs, and SSP sampling.
- [Medium] The logic to enable PERF_PMU_CAP_SIMD_REGS incorrectly couples the capability to the presence of non-SIMD extended features like CET_USER (SSP) and APX (eGPRs).
--

commit f179abf9419fef51aa84e8c413e619d7004c64c2
Author: Kan Liang <kan.liang@linux.intel.com>

perf/x86/intel: Enable PERF_PMU_CAP_SIMD_REGS capability

Enable the PERF_PMU_CAP_SIMD_REGS capability if XSAVES support is
available for YMM, ZMM, OPMASK, eGPRs, or SSP.

> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 679781519f8cf..eef5d116aa068 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -6316,6 +6316,26 @@ static void intel_extended_regs_init(struct pmu *pmu)
>  	 */
>  	x86_pmu.ext_regs_mask |= XFEATURE_MASK_SSE;
>  	dest_pmu->capabilities |= PERF_PMU_CAP_EXTENDED_REGS;

[Severity: High]
Does this skip the new SIMD capabilities on older PEBS V4+ architectures?

The initialization for YMM, ZMM, eGPRs, and SSP is only added to
intel_extended_regs_init(). Since intel_extended_regs_init() is called
by update_pmu_cap(), which is guarded by X86_FEATURE_ARCH_PERFMON_EXT,
architectures like Sapphire Rapids and Alder Lake appear to bypass this.

Should this logic also be replicated in intel_ds_pebs_init(), or should
intel_extended_regs_init() be called for those processors so they can
also support the new SIMD capabilities?

> +
> +	if (boot_cpu_has(X86_FEATURE_AVX) &&
> +	    cpu_has_xfeatures(XFEATURE_MASK_YMM, NULL))
> +		x86_pmu.ext_regs_mask |= XFEATURE_MASK_YMM;
> +	if (boot_cpu_has(X86_FEATURE_APX) &&
> +	    cpu_has_xfeatures(XFEATURE_MASK_APX, NULL))
> +		x86_pmu.ext_regs_mask |= XFEATURE_MASK_APX;
> +	if (boot_cpu_has(X86_FEATURE_AVX512F)) {
> +		if (cpu_has_xfeatures(XFEATURE_MASK_OPMASK, NULL))
> +			x86_pmu.ext_regs_mask |= XFEATURE_MASK_OPMASK;
> +		if (cpu_has_xfeatures(XFEATURE_MASK_ZMM_Hi256, NULL))
> +			x86_pmu.ext_regs_mask |= XFEATURE_MASK_ZMM_Hi256;
> +		if (cpu_has_xfeatures(XFEATURE_MASK_Hi16_ZMM, NULL))
> +			x86_pmu.ext_regs_mask |= XFEATURE_MASK_Hi16_ZMM;
> +	}
> +	if (cpu_feature_enabled(X86_FEATURE_USER_SHSTK))
> +		x86_pmu.ext_regs_mask |= XFEATURE_MASK_CET_USER;
> +
> +	if (x86_pmu.ext_regs_mask != XFEATURE_MASK_SSE)
> +		dest_pmu->capabilities |= PERF_PMU_CAP_SIMD_REGS;

[Severity: Medium]
Does this incorrectly couple the SIMD capability to non-SIMD features here?

If a processor supports SSE and CET_USER (SSP), ext_regs_mask will not equal
XFEATURE_MASK_SSE, and PERF_PMU_CAP_SIMD_REGS will be enabled.

However, if a processor only supports SSE, this condition evaluates to false,
and PERF_PMU_CAP_SIMD_REGS is omitted.

Could this regression force userspace tools to fall back to a separate legacy
path to sample XMM registers on SSE-only processors, rather than using the
unified sample_simd_regs interface?

>  }
>  
>  #define counter_mask(_gp, _fixed) ((_gp) | ((u64)(_fixed) << INTEL_PMC_IDX_FIXED))

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529075645.580362-1-dapeng1.mi@linux.intel.com?part=21