There are two event groups one for energy reporting and another
for "perf" events.

See the XML description files in https://github.com/intel/Intel-PMT
in the xml/CWF/OOBMSM/{RMID-ENERGY,RMID-PERF}/ for the detailed
descriptions that were used to derive these descriptions.

Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/kernel/cpu/resctrl/intel_aet.c | 54 +++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/arch/x86/kernel/cpu/resctrl/intel_aet.c b/arch/x86/kernel/cpu/resctrl/intel_aet.c
index 9a8ccb62b4ab..67862e81b9e0 100644
--- a/arch/x86/kernel/cpu/resctrl/intel_aet.c
+++ b/arch/x86/kernel/cpu/resctrl/intel_aet.c
@@ -94,8 +94,62 @@ struct telem_entry {
 	struct pmt_event evts[];
 };
 
+/*
+ * Known events from Intel Clearwater Forest CPU.
+ */
+#define CWF_NUM_RMIDS	576
+#define CWF_ENERGY_GUID	0x26696143
+#define CWF_PERF_GUID	0x26557651
+#define	CWF_ENERGY_STRIDE	0x10
+#define CWF_PERF_STRIDE	0x38
+
+/*
+ * https://github.com/intel/Intel-PMT
+ * xml/CWF/OOBMSM/RMID-ENERGY *.xml
+ */
+static struct telem_entry cwf_energy = {
+	.name				= "energy",
+	.guid				= CWF_ENERGY_GUID,
+	.num_rmids			= CWF_NUM_RMIDS,
+	.stride				= CWF_ENERGY_STRIDE,
+	.overflow_counter_off		= CWF_NUM_RMIDS * CWF_ENERGY_STRIDE,
+	.last_overflow_tstamp_off	= CWF_NUM_RMIDS * CWF_ENERGY_STRIDE + 8,
+	.last_update_tstamp_off		= CWF_NUM_RMIDS * CWF_ENERGY_STRIDE + 16,
+	.evts				= {
+		EVT(PMT_EVENT_ENERGY, "core_energy", 0x0, EVT_U46_18),
+		EVT(PMT_EVENT_ACTIVITY, "activity", 0x8, EVT_U46_18),
+		{ }
+	}
+};
+
+/*
+ * https://github.com/intel/Intel-PMT
+ * xml/CWF/OOBMSM/RMID-PERF *.xml
+ */
+static struct telem_entry cwf_perf = {
+	.name				= "perf",
+	.guid				= CWF_PERF_GUID,
+	.num_rmids			= CWF_NUM_RMIDS,
+	.stride				= CWF_PERF_STRIDE,
+	.overflow_counter_off		= CWF_NUM_RMIDS * CWF_PERF_STRIDE,
+	.last_overflow_tstamp_off	= CWF_NUM_RMIDS * CWF_PERF_STRIDE + 8,
+	.last_update_tstamp_off		= CWF_NUM_RMIDS * CWF_PERF_STRIDE + 16,
+	.evts				= {
+		EVT(PMT_EVENT_STALLS_LLC_HIT, "stalls_llc_hit", 0x0, EVT_U64),
+		EVT(PMT_EVENT_C1_RES, "c1_res", 0x8, EVT_U64),
+		EVT(PMT_EVENT_UNHALTED_CORE_CYCLES, "unhalted_core_cycles", 0x10, EVT_U64),
+		EVT(PMT_EVENT_STALLS_LLC_MISS, "stalls_llc_miss", 0x18, EVT_U64),
+		EVT(PMT_EVENT_AUTO_C6_RES, "c6_res", 0x20, EVT_U64),
+		EVT(PMT_EVENT_UNHALTED_REF_CYCLES, "unhalted_ref_cycles", 0x28, EVT_U64),
+		EVT(PMT_EVENT_UOPS_RETIRED, "uops_retired", 0x30, EVT_U64),
+		{ }
+	}
+};
+
 /* All known telemetry event groups */
 static struct telem_entry *telem_entry[] = {
+	&cwf_energy,
+	&cwf_perf,
 	NULL
 };
 
-- 
2.48.1

Hi Tony,

On 3/21/25 4:15 PM, Tony Luck wrote:
> There are two event groups one for energy reporting and another
> for "perf" events.
> 
> See the XML description files in https://github.com/intel/Intel-PMT
> in the xml/CWF/OOBMSM/{RMID-ENERGY,RMID-PERF}/ for the detailed
> descriptions that were used to derive these descriptions.

It is unexpected to me that this is made model specific while the
implementation is built around a guid. What will happen when
a new system using the same event layout arrives? Will the url
above be duplicated for this new system's acronym and contain
duplicate data? How will the resctrl support change? If I understand
correctly resctrl will not need to be changed but instead the "CWF"
events will just automatically be used for this new hypothetical
system? This makes me think that this should not be so CWF specific.

Reinette

On Mon, Mar 31, 2025 at 09:21:11AM -0700, Reinette Chatre wrote:
> Hi Tony,
> 
> On 3/21/25 4:15 PM, Tony Luck wrote:
> > There are two event groups one for energy reporting and another
> > for "perf" events.
> > 
> > See the XML description files in https://github.com/intel/Intel-PMT
> > in the xml/CWF/OOBMSM/{RMID-ENERGY,RMID-PERF}/ for the detailed
> > descriptions that were used to derive these descriptions.
> 
> It is unexpected to me that this is made model specific while the
> implementation is built around a guid. What will happen when
> a new system using the same event layout arrives? Will the url
> above be duplicated for this new system's acronym and contain
> duplicate data? How will the resctrl support change? If I understand
> correctly resctrl will not need to be changed but instead the "CWF"
> events will just automatically be used for this new hypothetical
> system? This makes me think that this should not be so CWF specific.

I was told that we might expect to see new guid values to describe
different event register layouts for the same CPU model. The event
aggregators are all firmware driven. So a BIOS update could make changes.

So I've left open the option to add additional structure defintions for
Clearwater Forest with some future firmware update.

If a future processor uses the exact same layout with the same guid value,
then no Linux update would be needed. We'd just have the slight oddity
that a structure named "cwf_*" would match and be used.

Next system to implement these telemetry events has a very different
list of supported events.

> Reinette

-Tony

Hi Tony,

On 3/31/25 3:07 PM, Luck, Tony wrote:
> On Mon, Mar 31, 2025 at 09:21:11AM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 3/21/25 4:15 PM, Tony Luck wrote:
>>> There are two event groups one for energy reporting and another
>>> for "perf" events.
>>>
>>> See the XML description files in https://github.com/intel/Intel-PMT
>>> in the xml/CWF/OOBMSM/{RMID-ENERGY,RMID-PERF}/ for the detailed
>>> descriptions that were used to derive these descriptions.
>>
>> It is unexpected to me that this is made model specific while the
>> implementation is built around a guid. What will happen when
>> a new system using the same event layout arrives? Will the url
>> above be duplicated for this new system's acronym and contain
>> duplicate data? How will the resctrl support change? If I understand
>> correctly resctrl will not need to be changed but instead the "CWF"
>> events will just automatically be used for this new hypothetical
>> system? This makes me think that this should not be so CWF specific.
> 
> I was told that we might expect to see new guid values to describe
> different event register layouts for the same CPU model. The event
> aggregators are all firmware driven. So a BIOS update could make changes.

Sounds like this supports my point. Naming these data structures based on
the CPU would create naming challenges when this scenario arrives, no?

> 
> So I've left open the option to add additional structure defintions for
> Clearwater Forest with some future firmware update.

Why not use the guid as part of the naming to make clear that CPU model
does not dictate the layout?


> 
> If a future processor uses the exact same layout with the same guid value,
> then no Linux update would be needed. We'd just have the slight oddity
> that a structure named "cwf_*" would match and be used.
> 
> Next system to implement these telemetry events has a very different
> list of supported events.
>

Reinette