Re: [Patch v8 2/5] perf regs: Support x86 eGPRs/SSP sampling

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Intel PT PEBS register synthesis is silently disabled on SIMD-capable machines.
- [Medium] Requesting legacy XMM registers (e.g., `-I XMM0`) fails with an 'Unknown register' error on modern CPUs, breaking backwards compatibility.
--

commit a0d7b85bb399d047c94284c24c34805466f84209
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
Subject: perf regs: Support x86 eGPRs/SSP sampling

This commit adds support for sampling x86 extended GP registers (R16-R31) and
the shadow stack pointer (SSP) register. It reclaims the original XMM registers
space in sample_regs_user/sample_regs_intr to represent the eGPRs and SSP when
SIMD sampling is supported, using a new abi argument to distinguish layouts.

> diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
> index fc9eec8b54b82..2729ad8c6d263 100644
> --- a/tools/perf/util/intel-pt.c
> +++ b/tools/perf/util/intel-pt.c
> @@ -2470,6 +2470,7 @@ static int intel_pt_do_synth_pebs_sample(struct intel_pt_queue *ptq, struct evse
>  	}
>  
>  	if (sample_type & PERF_SAMPLE_REGS_INTR &&
> +	    !evsel->core.attr.sample_simd_regs_enabled &&
>  	    (items->mask[INTEL_PT_GP_REGS_POS] ||
>  	     items->mask[INTEL_PT_XMM_POS])) {
>  		u64 regs_mask = evsel->core.attr.sample_regs_intr;

[Severity: Medium]
Does this completely disable PEBS register synthesis on SIMD-capable machines?

Since PERF_SAMPLE_REGS_ABI_SIMD is set by default on supported platforms in
__perf_reg_mask_x86(), opts->sample_simd_regs_enabled will be set to 1 for
any register request (like -I ax).

Could this cause basic GPR synthesis to be silently skipped here, resulting in
a functional regression for userspace tooling?

[ ... ]

> diff --git a/tools/perf/util/perf-regs-arch/perf_regs_x86.c b/tools/perf/util/perf-regs-arch/perf_regs_x86.c
> index b6d20522b4e8f..ae26d991cdc9f 100644
> --- a/tools/perf/util/perf-regs-arch/perf_regs_x86.c
> +++ b/tools/perf/util/perf-regs-arch/perf_regs_x86.c
> @@ -276,13 +276,38 @@ uint64_t __perf_reg_mask_x86(bool intr)
[ ... ]
> +uint64_t __perf_reg_mask_x86(bool intr, int *abi)
> +{
[ ... ]
> +	if (mask != PERF_REGS_MASK) {
> +		*abi |= PERF_SAMPLE_REGS_ABI_SIMD;
> +	} else {
> +		mask |= __arch__reg_mask(sample_type, PERF_REG_EXTENDED_MASK,
> +					 false);
>  	}
>  
> -	return PERF_REGS_MASK;
> +	return mask;
>  }
[ ... ]
> +const char *__perf_reg_name_x86(int id, int abi)
> +{
> +	const char *name;
> +
> +	name = __arch_reg_gpr_name(id);
> +	if (name)
> +		return name;
> +
> +	if (abi & PERF_SAMPLE_REGS_ABI_SIMD)
> +		name = __arch_reg_egpr_name(id);
> +	else
> +		name = __arch_reg_xmm_name(id);
> +
> +	return name;
> +}

[Severity: Medium]
Does this break backwards compatibility for legacy XMM register requests?

When the CPU supports eGPRs/SSP, PERF_SAMPLE_REGS_ABI_SIMD is set and the
legacy XMM registers (PERF_REG_EXTENDED_MASK) are excluded from the returned
mask because they share the same bit space.

If __perf_reg_name_x86() maps these overlapping IDs exclusively to eGPR names
(for instance, mapping ID 32 to R16), will name_to_perf_reg_mask() fail to
resolve legacy requests like -I XMM0 and throw an unknown register error?

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