Re: [Patch v2 17/24] perf/core: Support to capture higher width vector registers

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

On 2/26/2025 4:32 AM, Peter Zijlstra wrote:
> On Tue, Feb 18, 2025 at 03:28:11PM +0000, Dapeng Mi wrote:
>> diff --git a/arch/x86/include/uapi/asm/perf_regs.h b/arch/x86/include/uapi/asm/perf_regs.h
>> index 9ee9e55aed09..3851f627ca60 100644
>> --- a/arch/x86/include/uapi/asm/perf_regs.h
>> +++ b/arch/x86/include/uapi/asm/perf_regs.h
>> @@ -33,7 +33,7 @@ enum perf_event_x86_regs {
>>  	PERF_REG_X86_32_MAX = PERF_REG_X86_GS + 1,
>>  	PERF_REG_X86_64_MAX = PERF_REG_X86_SSP + 1,
>>  
>> -	/* These all need two bits set because they are 128bit */
>> +	/* These all need two bits set because they are 128 bits */
>>  	PERF_REG_X86_XMM0  = 32,
>>  	PERF_REG_X86_XMM1  = 34,
>>  	PERF_REG_X86_XMM2  = 36,
>> @@ -53,6 +53,87 @@ enum perf_event_x86_regs {
>>  
>>  	/* These include both GPRs and XMMX registers */
>>  	PERF_REG_X86_XMM_MAX = PERF_REG_X86_XMM15 + 2,
>> +
>> +	/*
>> +	 * YMM upper bits need two bits set because they are 128 bits.
>> +	 * PERF_REG_X86_YMMH0 = 64
>> +	 */
>> +	PERF_REG_X86_YMMH0	= PERF_REG_X86_XMM_MAX,
>> +	PERF_REG_X86_YMMH1	= PERF_REG_X86_YMMH0 + 2,
>> +	PERF_REG_X86_YMMH2	= PERF_REG_X86_YMMH1 + 2,
>> +	PERF_REG_X86_YMMH3	= PERF_REG_X86_YMMH2 + 2,
>> +	PERF_REG_X86_YMMH4	= PERF_REG_X86_YMMH3 + 2,
>> +	PERF_REG_X86_YMMH5	= PERF_REG_X86_YMMH4 + 2,
>> +	PERF_REG_X86_YMMH6	= PERF_REG_X86_YMMH5 + 2,
>> +	PERF_REG_X86_YMMH7	= PERF_REG_X86_YMMH6 + 2,
>> +	PERF_REG_X86_YMMH8	= PERF_REG_X86_YMMH7 + 2,
>> +	PERF_REG_X86_YMMH9	= PERF_REG_X86_YMMH8 + 2,
>> +	PERF_REG_X86_YMMH10	= PERF_REG_X86_YMMH9 + 2,
>> +	PERF_REG_X86_YMMH11	= PERF_REG_X86_YMMH10 + 2,
>> +	PERF_REG_X86_YMMH12	= PERF_REG_X86_YMMH11 + 2,
>> +	PERF_REG_X86_YMMH13	= PERF_REG_X86_YMMH12 + 2,
>> +	PERF_REG_X86_YMMH14	= PERF_REG_X86_YMMH13 + 2,
>> +	PERF_REG_X86_YMMH15	= PERF_REG_X86_YMMH14 + 2,
>> +	PERF_REG_X86_YMMH_MAX	= PERF_REG_X86_YMMH15 + 2,
>> +
>> +	/*
>> +	 * ZMM0-15 upper bits need four bits set because they are 256 bits
>> +	 * PERF_REG_X86_ZMMH0 = 96
>> +	 */
>> +	PERF_REG_X86_ZMMH0	= PERF_REG_X86_YMMH_MAX,
>> +	PERF_REG_X86_ZMMH1	= PERF_REG_X86_ZMMH0 + 4,
>> +	PERF_REG_X86_ZMMH2	= PERF_REG_X86_ZMMH1 + 4,
>> +	PERF_REG_X86_ZMMH3	= PERF_REG_X86_ZMMH2 + 4,
>> +	PERF_REG_X86_ZMMH4	= PERF_REG_X86_ZMMH3 + 4,
>> +	PERF_REG_X86_ZMMH5	= PERF_REG_X86_ZMMH4 + 4,
>> +	PERF_REG_X86_ZMMH6	= PERF_REG_X86_ZMMH5 + 4,
>> +	PERF_REG_X86_ZMMH7	= PERF_REG_X86_ZMMH6 + 4,
>> +	PERF_REG_X86_ZMMH8	= PERF_REG_X86_ZMMH7 + 4,
>> +	PERF_REG_X86_ZMMH9	= PERF_REG_X86_ZMMH8 + 4,
>> +	PERF_REG_X86_ZMMH10	= PERF_REG_X86_ZMMH9 + 4,
>> +	PERF_REG_X86_ZMMH11	= PERF_REG_X86_ZMMH10 + 4,
>> +	PERF_REG_X86_ZMMH12	= PERF_REG_X86_ZMMH11 + 4,
>> +	PERF_REG_X86_ZMMH13	= PERF_REG_X86_ZMMH12 + 4,
>> +	PERF_REG_X86_ZMMH14	= PERF_REG_X86_ZMMH13 + 4,
>> +	PERF_REG_X86_ZMMH15	= PERF_REG_X86_ZMMH14 + 4,
>> +	PERF_REG_X86_ZMMH_MAX	= PERF_REG_X86_ZMMH15 + 4,
>> +
>> +	/*
>> +	 * ZMM16-31 need eight bits set because they are 512 bits
>> +	 * PERF_REG_X86_ZMM16 = 160
>> +	 */
>> +	PERF_REG_X86_ZMM16	= PERF_REG_X86_ZMMH_MAX,
>> +	PERF_REG_X86_ZMM17	= PERF_REG_X86_ZMM16 + 8,
>> +	PERF_REG_X86_ZMM18	= PERF_REG_X86_ZMM17 + 8,
>> +	PERF_REG_X86_ZMM19	= PERF_REG_X86_ZMM18 + 8,
>> +	PERF_REG_X86_ZMM20	= PERF_REG_X86_ZMM19 + 8,
>> +	PERF_REG_X86_ZMM21	= PERF_REG_X86_ZMM20 + 8,
>> +	PERF_REG_X86_ZMM22	= PERF_REG_X86_ZMM21 + 8,
>> +	PERF_REG_X86_ZMM23	= PERF_REG_X86_ZMM22 + 8,
>> +	PERF_REG_X86_ZMM24	= PERF_REG_X86_ZMM23 + 8,
>> +	PERF_REG_X86_ZMM25	= PERF_REG_X86_ZMM24 + 8,
>> +	PERF_REG_X86_ZMM26	= PERF_REG_X86_ZMM25 + 8,
>> +	PERF_REG_X86_ZMM27	= PERF_REG_X86_ZMM26 + 8,
>> +	PERF_REG_X86_ZMM28	= PERF_REG_X86_ZMM27 + 8,
>> +	PERF_REG_X86_ZMM29	= PERF_REG_X86_ZMM28 + 8,
>> +	PERF_REG_X86_ZMM30	= PERF_REG_X86_ZMM29 + 8,
>> +	PERF_REG_X86_ZMM31	= PERF_REG_X86_ZMM30 + 8,
>> +	PERF_REG_X86_ZMM_MAX	= PERF_REG_X86_ZMM31 + 8,
>> +
>> +	/*
>> +	 * OPMASK Registers
>> +	 * PERF_REG_X86_OPMASK0 = 288
>> +	 */
>> +	PERF_REG_X86_OPMASK0	= PERF_REG_X86_ZMM_MAX,
>> +	PERF_REG_X86_OPMASK1	= PERF_REG_X86_OPMASK0 + 1,
>> +	PERF_REG_X86_OPMASK2	= PERF_REG_X86_OPMASK1 + 1,
>> +	PERF_REG_X86_OPMASK3	= PERF_REG_X86_OPMASK2 + 1,
>> +	PERF_REG_X86_OPMASK4	= PERF_REG_X86_OPMASK3 + 1,
>> +	PERF_REG_X86_OPMASK5	= PERF_REG_X86_OPMASK4 + 1,
>> +	PERF_REG_X86_OPMASK6	= PERF_REG_X86_OPMASK5 + 1,
>> +	PERF_REG_X86_OPMASK7	= PERF_REG_X86_OPMASK6 + 1,
>> +
>> +	PERF_REG_X86_VEC_MAX	= PERF_REG_X86_OPMASK7 + 1,
>>  };
>>  
>>  #define PERF_REG_EXTENDED_MASK	(~((1ULL << PERF_REG_X86_XMM0) - 1))
>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>> index 0524d541d4e3..8a17d696d78c 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -379,6 +379,10 @@ enum perf_event_read_format {
>>  #define PERF_ATTR_SIZE_VER6	120	/* add: aux_sample_size */
>>  #define PERF_ATTR_SIZE_VER7	128	/* add: sig_data */
>>  #define PERF_ATTR_SIZE_VER8	136	/* add: config3 */
>> +#define PERF_ATTR_SIZE_VER9	168	/* add: sample_regs_intr_ext[PERF_EXT_REGS_ARRAY_SIZE] */
>> +
>> +#define PERF_EXT_REGS_ARRAY_SIZE	4
>> +#define PERF_NUM_EXT_REGS		(PERF_EXT_REGS_ARRAY_SIZE * 64)
>>  
>>  /*
>>   * Hardware event_id to monitor via a performance monitoring event:
>> @@ -531,6 +535,13 @@ struct perf_event_attr {
>>  	__u64	sig_data;
>>  
>>  	__u64	config3; /* extension of config2 */
>> +
>> +	/*
>> +	 * Extension sets of regs to dump for each sample.
>> +	 * See asm/perf_regs.h for details.
>> +	 */
>> +	__u64	sample_regs_intr_ext[PERF_EXT_REGS_ARRAY_SIZE];
>> +	__u64   sample_regs_user_ext[PERF_EXT_REGS_ARRAY_SIZE];
>>  };
>>  
>>  /*
> *groan*... so do people really need per-register (or even partial
> register) masks for all this?

Yeah, I agree. Users should never read partial registers. But as current
perf tool has already supported to read per-register on XMM registers, not
sure if it would introduce back-compatible issues if we only support read
register group, like XMM, YMM or ZMM group.


>
> Or can we perhaps -- like XSAVE/PEBS -- do it per register group?

If there is no back-compatible issue, I think it should work.


>
> Also, we're going to be getting EGPRs, which I think just about fit in
> this 320 bit mask we now have, but it is quite insane.
>