[QUESTION] ARM DSU PMU: 32-bit counter assumption and handling of 64-bit event counters

["feng.zhou" <realsummitzhou@gmail.com>]

Hi Will and Mark,

I have a question regarding the ARM DSU PMU driver implementation in
drivers/perf/arm_dsu_pmu.c, specifically about the counter width
assumptions.

Current Implementation:
======================
The driver currently assumes all event counters are 32-bit wide, with
only the cycle counter being 64-bit (lines 69-71):

/* All event counters are 32bit, with a 64bit Cycle counter */
#define DSU_PMU_COUNTER_WIDTH(idx)	\
	(((idx) == DSU_PMU_IDX_CYCLE_COUNTER) ? 64 : 32)

This assumption is used throughout the code for handling counter
overflow and calculating deltas (e.g., line 344 in dsu_pmu_event_update).

Issue Observed:
===============
I've encountered overflow issues when using perf tools on newer ARM CPUs
where the event counters appear to be 64-bit rather than 32-bit. The
current implementation causes incorrect event counting and potential data
loss due to premature overflow handling based on the 32-bit mask.

Questions:
==========
1. Is the 32-bit event counter assumption based on the ARMv8 PMU
   specification or DSU-specific hardware documentation?

2. Are there known ARM CPU implementations where DSU event counters
   exceed 32 bits? If so, how should the driver handle this variation?

3. Would it be appropriate to detect the actual counter width at runtime
   (similar to how num_counters is probed in dsu_pmu_probe_pmu), or
   should this be handled through device tree / ACPI properties?

4. Should there be a mechanism to query the hardware for the actual
   counter width to ensure compatibility with future implementations?

Thank you for your time and any insights you can provide.


Best regards,
Feng