[PATCH 0/3] perf/x86/intel: Various small fixes for core PMU

[PATCH 0/3] perf/x86/intel: Various small fixes for core PMU

[kan.liang]

From: Kan Liang <kan.liang@linux.intel.com>

Several small fixes for core PMU were sent in the past few months. They
were buried in the LKML. The patch set is to resend them.

These patches are standalone and can be merged separately.

Patch 1 is to hide unenumerated Topdowm metrics events.
The original patch can be found at
https://lore.kernel.org/lkml/20231219150109.1596634-1-kan.liang@linux.intel.com/

Patch 2 is to add a distinct name for Granite Rapids
The original patch can be found at
https://lore.kernel.org/lkml/20240426150557.2857936-1-kan.liang@linux.intel.com/

Patch 3 is to fix non 0 retire latency on Raptor Lake
The original patch can be found at
https://lore.kernel.org/lkml/20240405143032.1243201-1-kan.liang@linux.intel.com/

Kan Liang (3):
  perf/x86/intel: Hide Topdown metrics events if the feature is not
    enumerated
  perf/x86/intel: Add a distinct name for Granite Rapids
  perf/x86/intel/ds: Fix non 0 retire latency on Raptorlake

 arch/x86/events/intel/core.c | 43 ++++++++++++++++++++++++++++++++----
 arch/x86/events/intel/ds.c   |  8 +++++--
 2 files changed, 45 insertions(+), 6 deletions(-)

-- 
2.38.1

[PATCH 1/3] perf/x86/intel: Hide Topdown metrics events if the feature is not enumerated

[kan.liang]

From: Kan Liang <kan.liang@linux.intel.com>

The below error is observed on Ice Lake VM.

$ perf stat
Error:
The sys_perf_event_open() syscall returned with 22 (Invalid argument)
for event (slots).
/bin/dmesg | grep -i perf may provide additional information.

In a virtualization env, the Topdown metrics and the slots event haven't
been supported yet. The guest CPUID doesn't enumerate them. However, the
current kernel unconditionally exposes the slots event and the Topdown
metrics events to sysfs, which misleads the perf tool and triggers the
error.

Hide the perf-metrics topdown events and the slots event if the
perf-metrics feature is not enumerated.

The big core of a hybrid platform can also supports the perf-metrics
feature. Fix the hybrid platform as well.

Reported-by: Dongli Zhang <dongli.zhang@oracle.com>
Closes: https://lore.kernel.org/lkml/CAM9d7cj8z+ryyzUHR+P1Dcpot2jjW+Qcc4CPQpfafTXN=LEU0Q@mail.gmail.com/
Tested-by: Dongli Zhang <dongli.zhang@oracle.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
---
 arch/x86/events/intel/core.c | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index cd8f2db6cdf6..b61367991a16 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -5830,8 +5830,22 @@ exra_is_visible(struct kobject *kobj, struct attribute *attr, int i)
 	return x86_pmu.version >= 2 ? attr->mode : 0;
 }
 
+static umode_t
+td_is_visible(struct kobject *kobj, struct attribute *attr, int i)
+{
+	/*
+	 * Hide the perf metrics topdown events
+	 * if the feature is not enumerated.
+	 */
+	if (x86_pmu.num_topdown_events)
+		return x86_pmu.intel_cap.perf_metrics ? attr->mode : 0;
+
+	return attr->mode;
+}
+
 static struct attribute_group group_events_td  = {
 	.name = "events",
+	.is_visible = td_is_visible,
 };
 
 static struct attribute_group group_events_mem = {
@@ -6057,9 +6071,27 @@ static umode_t hybrid_format_is_visible(struct kobject *kobj,
 	return (cpu >= 0) && (pmu->pmu_type & pmu_attr->pmu_type) ? attr->mode : 0;
 }
 
+static umode_t hybrid_td_is_visible(struct kobject *kobj,
+				    struct attribute *attr, int i)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct x86_hybrid_pmu *pmu =
+		 container_of(dev_get_drvdata(dev), struct x86_hybrid_pmu, pmu);
+
+	if (!is_attr_for_this_pmu(kobj, attr))
+		return 0;
+
+
+	/* Only the big core supports perf metrics */
+	if (pmu->pmu_type == hybrid_big)
+		return pmu->intel_cap.perf_metrics ? attr->mode : 0;
+
+	return attr->mode;
+}
+
 static struct attribute_group hybrid_group_events_td  = {
 	.name		= "events",
-	.is_visible	= hybrid_events_is_visible,
+	.is_visible	= hybrid_td_is_visible,
 };
 
 static struct attribute_group hybrid_group_events_mem = {
-- 
2.38.1

[tip: perf/core] perf/x86/intel: Hide Topdown metrics events if the feature is not enumerated

[tip-bot2 for Kan Liang]

The following commit has been merged into the perf/core branch of tip:

Commit-ID:     556a7c039a52c21da33eaae9269984a1ef59189b
Gitweb:        https://git.kernel.org/tip/556a7c039a52c21da33eaae9269984a1ef59189b
Author:        Kan Liang <kan.liang@linux.intel.com>
AuthorDate:    Mon, 08 Jul 2024 12:33:34 -07:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 09 Jul 2024 13:26:38 +02:00

perf/x86/intel: Hide Topdown metrics events if the feature is not enumerated

The below error is observed on Ice Lake VM.

$ perf stat
Error:
The sys_perf_event_open() syscall returned with 22 (Invalid argument)
for event (slots).
/bin/dmesg | grep -i perf may provide additional information.

In a virtualization env, the Topdown metrics and the slots event haven't
been supported yet. The guest CPUID doesn't enumerate them. However, the
current kernel unconditionally exposes the slots event and the Topdown
metrics events to sysfs, which misleads the perf tool and triggers the
error.

Hide the perf-metrics topdown events and the slots event if the
perf-metrics feature is not enumerated.

The big core of a hybrid platform can also supports the perf-metrics
feature. Fix the hybrid platform as well.

Closes: https://lore.kernel.org/lkml/CAM9d7cj8z+ryyzUHR+P1Dcpot2jjW+Qcc4CPQpfafTXN=LEU0Q@mail.gmail.com/
Reported-by: Dongli Zhang <dongli.zhang@oracle.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Dongli Zhang <dongli.zhang@oracle.com>
Link: https://lkml.kernel.org/r/20240708193336.1192217-2-kan.liang@linux.intel.com
---
 arch/x86/events/intel/core.c | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index cd8f2db..b613679 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -5830,8 +5830,22 @@ exra_is_visible(struct kobject *kobj, struct attribute *attr, int i)
 	return x86_pmu.version >= 2 ? attr->mode : 0;
 }
 
+static umode_t
+td_is_visible(struct kobject *kobj, struct attribute *attr, int i)
+{
+	/*
+	 * Hide the perf metrics topdown events
+	 * if the feature is not enumerated.
+	 */
+	if (x86_pmu.num_topdown_events)
+		return x86_pmu.intel_cap.perf_metrics ? attr->mode : 0;
+
+	return attr->mode;
+}
+
 static struct attribute_group group_events_td  = {
 	.name = "events",
+	.is_visible = td_is_visible,
 };
 
 static struct attribute_group group_events_mem = {
@@ -6057,9 +6071,27 @@ static umode_t hybrid_format_is_visible(struct kobject *kobj,
 	return (cpu >= 0) && (pmu->pmu_type & pmu_attr->pmu_type) ? attr->mode : 0;
 }
 
+static umode_t hybrid_td_is_visible(struct kobject *kobj,
+				    struct attribute *attr, int i)
+{
+	struct device *dev = kobj_to_dev(kobj);
+	struct x86_hybrid_pmu *pmu =
+		 container_of(dev_get_drvdata(dev), struct x86_hybrid_pmu, pmu);
+
+	if (!is_attr_for_this_pmu(kobj, attr))
+		return 0;
+
+
+	/* Only the big core supports perf metrics */
+	if (pmu->pmu_type == hybrid_big)
+		return pmu->intel_cap.perf_metrics ? attr->mode : 0;
+
+	return attr->mode;
+}
+
 static struct attribute_group hybrid_group_events_td  = {
 	.name		= "events",
-	.is_visible	= hybrid_events_is_visible,
+	.is_visible	= hybrid_td_is_visible,
 };
 
 static struct attribute_group hybrid_group_events_mem = {

[PATCH 2/3] perf/x86/intel: Add a distinct name for Granite Rapids

[kan.liang]

From: Kan Liang <kan.liang@linux.intel.com>

Currently, the Sapphire Rapids and Granite Rapids share the same PMU
name, sapphire_rapids. Because from the kernel’s perspective, GNR is
similar to SPR. The only key difference is that they support different
extra MSRs. The code path and the PMU name are shared.

However, from end users' perspective, they are quite different. Besides
the extra MSRs, GNR has a newer PEBS format, supports Retire Latency,
supports new CPUID enumeration architecture, doesn't required the
load-latency AUX event, has additional TMA Level 1 Architectural Events,
etc. The differences can be enumerated by CPUID or the PERF_CAPABILITIES
MSR. They weren't reflected in the model-specific kernel setup.
But it is worth to have a distinct PMU name for GNR.

Fixes: a6742cb90b56 ("perf/x86/intel: Fix the FRONTEND encoding on GNR and MTL")
Suggested-by: Ahmad Yasin <ahmad.yasin@intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Cc: stable@vger.kernel.org
---
 arch/x86/events/intel/core.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index b61367991a16..7a9f931a1f48 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -6943,12 +6943,17 @@ __init int intel_pmu_init(void)
 	case INTEL_EMERALDRAPIDS_X:
 		x86_pmu.flags |= PMU_FL_MEM_LOADS_AUX;
 		x86_pmu.extra_regs = intel_glc_extra_regs;
+		pr_cont("Sapphire Rapids events, ");
+		name = "sapphire_rapids";
 		fallthrough;
 	case INTEL_GRANITERAPIDS_X:
 	case INTEL_GRANITERAPIDS_D:
 		intel_pmu_init_glc(NULL);
-		if (!x86_pmu.extra_regs)
+		if (!x86_pmu.extra_regs) {
 			x86_pmu.extra_regs = intel_rwc_extra_regs;
+			pr_cont("Granite Rapids events, ");
+			name = "granite_rapids";
+		}
 		x86_pmu.pebs_ept = 1;
 		x86_pmu.hw_config = hsw_hw_config;
 		x86_pmu.get_event_constraints = glc_get_event_constraints;
@@ -6959,8 +6964,6 @@ __init int intel_pmu_init(void)
 		td_attr = glc_td_events_attrs;
 		tsx_attr = glc_tsx_events_attrs;
 		intel_pmu_pebs_data_source_skl(true);
-		pr_cont("Sapphire Rapids events, ");
-		name = "sapphire_rapids";
 		break;
 
 	case INTEL_ALDERLAKE:
-- 
2.38.1

Re: [PATCH 2/3] perf/x86/intel: Add a distinct name for Granite Rapids

[Peter Zijlstra]

On Mon, Jul 08, 2024 at 12:33:35PM -0700, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
> 
> Currently, the Sapphire Rapids and Granite Rapids share the same PMU
> name, sapphire_rapids. Because from the kernel’s perspective, GNR is
> similar to SPR. The only key difference is that they support different
> extra MSRs. The code path and the PMU name are shared.
> 
> However, from end users' perspective, they are quite different. Besides
> the extra MSRs, GNR has a newer PEBS format, supports Retire Latency,
> supports new CPUID enumeration architecture, doesn't required the
> load-latency AUX event, has additional TMA Level 1 Architectural Events,
> etc. The differences can be enumerated by CPUID or the PERF_CAPABILITIES
> MSR. They weren't reflected in the model-specific kernel setup.
> But it is worth to have a distinct PMU name for GNR.
> 
> Fixes: a6742cb90b56 ("perf/x86/intel: Fix the FRONTEND encoding on GNR and MTL")
> Suggested-by: Ahmad Yasin <ahmad.yasin@intel.com>
> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> Cc: stable@vger.kernel.org
> ---
>  arch/x86/events/intel/core.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index b61367991a16..7a9f931a1f48 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -6943,12 +6943,17 @@ __init int intel_pmu_init(void)
>  	case INTEL_EMERALDRAPIDS_X:
>  		x86_pmu.flags |= PMU_FL_MEM_LOADS_AUX;
>  		x86_pmu.extra_regs = intel_glc_extra_regs;
> +		pr_cont("Sapphire Rapids events, ");
> +		name = "sapphire_rapids";
>  		fallthrough;
>  	case INTEL_GRANITERAPIDS_X:
>  	case INTEL_GRANITERAPIDS_D:
>  		intel_pmu_init_glc(NULL);
> -		if (!x86_pmu.extra_regs)
> +		if (!x86_pmu.extra_regs) {
>  			x86_pmu.extra_regs = intel_rwc_extra_regs;
> +			pr_cont("Granite Rapids events, ");
> +			name = "granite_rapids";
> +		}
>  		x86_pmu.pebs_ept = 1;
>  		x86_pmu.hw_config = hsw_hw_config;
>  		x86_pmu.get_event_constraints = glc_get_event_constraints;
> @@ -6959,8 +6964,6 @@ __init int intel_pmu_init(void)
>  		td_attr = glc_td_events_attrs;
>  		tsx_attr = glc_tsx_events_attrs;
>  		intel_pmu_pebs_data_source_skl(true);
> -		pr_cont("Sapphire Rapids events, ");
> -		name = "sapphire_rapids";
>  		break;

For some reason this didn't want to apply cleanly (something trivial),
but since I had to edit it, my fingers slipped and I ended up with the
below. That ok?

---
Subject: perf/x86/intel: Add a distinct name for Granite Rapids
From: Kan Liang <kan.liang@linux.intel.com>
Date: Mon, 8 Jul 2024 12:33:35 -0700

From: Kan Liang <kan.liang@linux.intel.com>

Currently, the Sapphire Rapids and Granite Rapids share the same PMU
name, sapphire_rapids. Because from the kernel’s perspective, GNR is
similar to SPR. The only key difference is that they support different
extra MSRs. The code path and the PMU name are shared.

However, from end users' perspective, they are quite different. Besides
the extra MSRs, GNR has a newer PEBS format, supports Retire Latency,
supports new CPUID enumeration architecture, doesn't required the
load-latency AUX event, has additional TMA Level 1 Architectural Events,
etc. The differences can be enumerated by CPUID or the PERF_CAPABILITIES
MSR. They weren't reflected in the model-specific kernel setup.
But it is worth to have a distinct PMU name for GNR.

Fixes: a6742cb90b56 ("perf/x86/intel: Fix the FRONTEND encoding on GNR and MTL")
Suggested-by: Ahmad Yasin <ahmad.yasin@intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20240708193336.1192217-3-kan.liang@linux.intel.com
---
 arch/x86/events/intel/core.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -6788,12 +6788,18 @@ __init int intel_pmu_init(void)
 	case INTEL_FAM6_EMERALDRAPIDS_X:
 		x86_pmu.flags |= PMU_FL_MEM_LOADS_AUX;
 		x86_pmu.extra_regs = intel_glc_extra_regs;
-		fallthrough;
+		pr_cont("Sapphire Rapids events, ");
+		name = "sapphire_rapids";
+		goto glc_common;
+
 	case INTEL_FAM6_GRANITERAPIDS_X:
 	case INTEL_FAM6_GRANITERAPIDS_D:
+		x86_pmu.extra_regs = intel_rwc_extra_regs;
+		pr_cont("Granite Rapids events, ");
+		name = "granite_rapids";
+
+	glc_common:
 		intel_pmu_init_glc(NULL);
-		if (!x86_pmu.extra_regs)
-			x86_pmu.extra_regs = intel_rwc_extra_regs;
 		x86_pmu.pebs_ept = 1;
 		x86_pmu.hw_config = hsw_hw_config;
 		x86_pmu.get_event_constraints = glc_get_event_constraints;
@@ -6804,8 +6810,6 @@ __init int intel_pmu_init(void)
 		td_attr = glc_td_events_attrs;
 		tsx_attr = glc_tsx_events_attrs;
 		intel_pmu_pebs_data_source_skl(true);
-		pr_cont("Sapphire Rapids events, ");
-		name = "sapphire_rapids";
 		break;
 
 	case INTEL_FAM6_ALDERLAKE:

Re: [PATCH 2/3] perf/x86/intel: Add a distinct name for Granite Rapids

[Liang, Kan]

On 2024-07-09 5:56 a.m., Peter Zijlstra wrote:
> On Mon, Jul 08, 2024 at 12:33:35PM -0700, kan.liang@linux.intel.com wrote:
>> From: Kan Liang <kan.liang@linux.intel.com>
>>
>> Currently, the Sapphire Rapids and Granite Rapids share the same PMU
>> name, sapphire_rapids. Because from the kernel’s perspective, GNR is
>> similar to SPR. The only key difference is that they support different
>> extra MSRs. The code path and the PMU name are shared.
>>
>> However, from end users' perspective, they are quite different. Besides
>> the extra MSRs, GNR has a newer PEBS format, supports Retire Latency,
>> supports new CPUID enumeration architecture, doesn't required the
>> load-latency AUX event, has additional TMA Level 1 Architectural Events,
>> etc. The differences can be enumerated by CPUID or the PERF_CAPABILITIES
>> MSR. They weren't reflected in the model-specific kernel setup.
>> But it is worth to have a distinct PMU name for GNR.
>>
>> Fixes: a6742cb90b56 ("perf/x86/intel: Fix the FRONTEND encoding on GNR and MTL")
>> Suggested-by: Ahmad Yasin <ahmad.yasin@intel.com>
>> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
>> Cc: stable@vger.kernel.org
>> ---
>>  arch/x86/events/intel/core.c | 9 ++++++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index b61367991a16..7a9f931a1f48 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -6943,12 +6943,17 @@ __init int intel_pmu_init(void)
>>  	case INTEL_EMERALDRAPIDS_X:
>>  		x86_pmu.flags |= PMU_FL_MEM_LOADS_AUX;
>>  		x86_pmu.extra_regs = intel_glc_extra_regs;
>> +		pr_cont("Sapphire Rapids events, ");
>> +		name = "sapphire_rapids";
>>  		fallthrough;
>>  	case INTEL_GRANITERAPIDS_X:
>>  	case INTEL_GRANITERAPIDS_D:
>>  		intel_pmu_init_glc(NULL);
>> -		if (!x86_pmu.extra_regs)
>> +		if (!x86_pmu.extra_regs) {
>>  			x86_pmu.extra_regs = intel_rwc_extra_regs;
>> +			pr_cont("Granite Rapids events, ");
>> +			name = "granite_rapids";
>> +		}
>>  		x86_pmu.pebs_ept = 1;
>>  		x86_pmu.hw_config = hsw_hw_config;
>>  		x86_pmu.get_event_constraints = glc_get_event_constraints;
>> @@ -6959,8 +6964,6 @@ __init int intel_pmu_init(void)
>>  		td_attr = glc_td_events_attrs;
>>  		tsx_attr = glc_tsx_events_attrs;
>>  		intel_pmu_pebs_data_source_skl(true);
>> -		pr_cont("Sapphire Rapids events, ");
>> -		name = "sapphire_rapids";
>>  		break;
> 
> For some reason this didn't want to apply cleanly (something trivial),
> but since I had to edit it, my fingers slipped and I ended up with the
> below. That ok?

Yes, the patch looks good. Thanks!

Thanks,
Kan
> 
> ---
> Subject: perf/x86/intel: Add a distinct name for Granite Rapids
> From: Kan Liang <kan.liang@linux.intel.com>
> Date: Mon, 8 Jul 2024 12:33:35 -0700
> 
> From: Kan Liang <kan.liang@linux.intel.com>
> 
> Currently, the Sapphire Rapids and Granite Rapids share the same PMU
> name, sapphire_rapids. Because from the kernel’s perspective, GNR is
> similar to SPR. The only key difference is that they support different
> extra MSRs. The code path and the PMU name are shared.
> 
> However, from end users' perspective, they are quite different. Besides
> the extra MSRs, GNR has a newer PEBS format, supports Retire Latency,
> supports new CPUID enumeration architecture, doesn't required the
> load-latency AUX event, has additional TMA Level 1 Architectural Events,
> etc. The differences can be enumerated by CPUID or the PERF_CAPABILITIES
> MSR. They weren't reflected in the model-specific kernel setup.
> But it is worth to have a distinct PMU name for GNR.
> 
> Fixes: a6742cb90b56 ("perf/x86/intel: Fix the FRONTEND encoding on GNR and MTL")
> Suggested-by: Ahmad Yasin <ahmad.yasin@intel.com>
> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: stable@vger.kernel.org
> Link: https://lkml.kernel.org/r/20240708193336.1192217-3-kan.liang@linux.intel.com
> ---
>  arch/x86/events/intel/core.c |   14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -6788,12 +6788,18 @@ __init int intel_pmu_init(void)
>  	case INTEL_FAM6_EMERALDRAPIDS_X:
>  		x86_pmu.flags |= PMU_FL_MEM_LOADS_AUX;
>  		x86_pmu.extra_regs = intel_glc_extra_regs;
> -		fallthrough;
> +		pr_cont("Sapphire Rapids events, ");
> +		name = "sapphire_rapids";
> +		goto glc_common;
> +
>  	case INTEL_FAM6_GRANITERAPIDS_X:
>  	case INTEL_FAM6_GRANITERAPIDS_D:
> +		x86_pmu.extra_regs = intel_rwc_extra_regs;
> +		pr_cont("Granite Rapids events, ");
> +		name = "granite_rapids";
> +
> +	glc_common:
>  		intel_pmu_init_glc(NULL);
> -		if (!x86_pmu.extra_regs)
> -			x86_pmu.extra_regs = intel_rwc_extra_regs;
>  		x86_pmu.pebs_ept = 1;
>  		x86_pmu.hw_config = hsw_hw_config;
>  		x86_pmu.get_event_constraints = glc_get_event_constraints;
> @@ -6804,8 +6810,6 @@ __init int intel_pmu_init(void)
>  		td_attr = glc_td_events_attrs;
>  		tsx_attr = glc_tsx_events_attrs;
>  		intel_pmu_pebs_data_source_skl(true);
> -		pr_cont("Sapphire Rapids events, ");
> -		name = "sapphire_rapids";
>  		break;
>  
>  	case INTEL_FAM6_ALDERLAKE:
> 

[tip: perf/core] perf/x86/intel: Add a distinct name for Granite Rapids

[tip-bot2 for Kan Liang]

The following commit has been merged into the perf/core branch of tip:

Commit-ID:     fa0c1c9d283b37fdb7fc1dcccbb88fc8f48a4aa4
Gitweb:        https://git.kernel.org/tip/fa0c1c9d283b37fdb7fc1dcccbb88fc8f48a4aa4
Author:        Kan Liang <kan.liang@linux.intel.com>
AuthorDate:    Mon, 08 Jul 2024 12:33:35 -07:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 09 Jul 2024 13:26:39 +02:00

perf/x86/intel: Add a distinct name for Granite Rapids

Currently, the Sapphire Rapids and Granite Rapids share the same PMU
name, sapphire_rapids. Because from the kernel’s perspective, GNR is
similar to SPR. The only key difference is that they support different
extra MSRs. The code path and the PMU name are shared.

However, from end users' perspective, they are quite different. Besides
the extra MSRs, GNR has a newer PEBS format, supports Retire Latency,
supports new CPUID enumeration architecture, doesn't required the
load-latency AUX event, has additional TMA Level 1 Architectural Events,
etc. The differences can be enumerated by CPUID or the PERF_CAPABILITIES
MSR. They weren't reflected in the model-specific kernel setup.
But it is worth to have a distinct PMU name for GNR.

Fixes: a6742cb90b56 ("perf/x86/intel: Fix the FRONTEND encoding on GNR and MTL")
Suggested-by: Ahmad Yasin <ahmad.yasin@intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20240708193336.1192217-3-kan.liang@linux.intel.com
---
 arch/x86/events/intel/core.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index b613679..0c9c270 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -6943,12 +6943,18 @@ __init int intel_pmu_init(void)
 	case INTEL_EMERALDRAPIDS_X:
 		x86_pmu.flags |= PMU_FL_MEM_LOADS_AUX;
 		x86_pmu.extra_regs = intel_glc_extra_regs;
-		fallthrough;
+		pr_cont("Sapphire Rapids events, ");
+		name = "sapphire_rapids";
+		goto glc_common;
+
 	case INTEL_GRANITERAPIDS_X:
 	case INTEL_GRANITERAPIDS_D:
+		x86_pmu.extra_regs = intel_rwc_extra_regs;
+		pr_cont("Granite Rapids events, ");
+		name = "granite_rapids";
+
+	glc_common:
 		intel_pmu_init_glc(NULL);
-		if (!x86_pmu.extra_regs)
-			x86_pmu.extra_regs = intel_rwc_extra_regs;
 		x86_pmu.pebs_ept = 1;
 		x86_pmu.hw_config = hsw_hw_config;
 		x86_pmu.get_event_constraints = glc_get_event_constraints;
@@ -6959,8 +6965,6 @@ __init int intel_pmu_init(void)
 		td_attr = glc_td_events_attrs;
 		tsx_attr = glc_tsx_events_attrs;
 		intel_pmu_pebs_data_source_skl(true);
-		pr_cont("Sapphire Rapids events, ");
-		name = "sapphire_rapids";
 		break;
 
 	case INTEL_ALDERLAKE:

[PATCH 3/3] perf/x86/intel/ds: Fix non 0 retire latency on Raptorlake

[kan.liang]

From: Kan Liang <kan.liang@linux.intel.com>

A non-0 retire latency can be observed on a Raptorlake which doesn't
support the retire latency feature.
By design, the retire latency shares the PERF_SAMPLE_WEIGHT_STRUCT
sample type with other types of latency. That could avoid adding too
many different sample types to support all kinds of latency. For the
machine which doesn't support some kind of latency, 0 should be
returned.

Perf doesn’t clear/init all the fields of a sample data for the sake
of performance. It expects the later perf_{prepare,output}_sample() to
update the uninitialized field. However, the current implementation
doesn't touch the field of the retire latency if the feature is not
supported. The memory garbage is dumped into the perf data.

Clear the retire latency if the feature is not supported.

Fixes: c87a31093c70 ("perf/x86: Support Retire Latency")
Reported-by: "Bayduraev, Alexey V" <alexey.v.bayduraev@intel.com>
Tested-by: "Bayduraev, Alexey V" <alexey.v.bayduraev@intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Cc: stable@vger.kernel.org
---
 arch/x86/events/intel/ds.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index b9cc520b2942..fa5ea65de0d0 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1944,8 +1944,12 @@ static void setup_pebs_adaptive_sample_data(struct perf_event *event,
 	set_linear_ip(regs, basic->ip);
 	regs->flags = PERF_EFLAGS_EXACT;
 
-	if ((sample_type & PERF_SAMPLE_WEIGHT_STRUCT) && (x86_pmu.flags & PMU_FL_RETIRE_LATENCY))
-		data->weight.var3_w = format_size >> PEBS_RETIRE_LATENCY_OFFSET & PEBS_LATENCY_MASK;
+	if (sample_type & PERF_SAMPLE_WEIGHT_STRUCT) {
+		if (x86_pmu.flags & PMU_FL_RETIRE_LATENCY)
+			data->weight.var3_w = format_size >> PEBS_RETIRE_LATENCY_OFFSET & PEBS_LATENCY_MASK;
+		else
+			data->weight.var3_w = 0;
+	}
 
 	/*
 	 * The record for MEMINFO is in front of GP
-- 
2.38.1

[tip: perf/core] perf/x86/intel/ds: Fix non 0 retire latency on Raptorlake

[tip-bot2 for Kan Liang]

The following commit has been merged into the perf/core branch of tip:

Commit-ID:     e5f32ad56b22ebe384a6e7ddad6e9520c5495563
Gitweb:        https://git.kernel.org/tip/e5f32ad56b22ebe384a6e7ddad6e9520c5495563
Author:        Kan Liang <kan.liang@linux.intel.com>
AuthorDate:    Mon, 08 Jul 2024 12:33:36 -07:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 09 Jul 2024 13:26:39 +02:00

perf/x86/intel/ds: Fix non 0 retire latency on Raptorlake

A non-0 retire latency can be observed on a Raptorlake which doesn't
support the retire latency feature.
By design, the retire latency shares the PERF_SAMPLE_WEIGHT_STRUCT
sample type with other types of latency. That could avoid adding too
many different sample types to support all kinds of latency. For the
machine which doesn't support some kind of latency, 0 should be
returned.

Perf doesn’t clear/init all the fields of a sample data for the sake
of performance. It expects the later perf_{prepare,output}_sample() to
update the uninitialized field. However, the current implementation
doesn't touch the field of the retire latency if the feature is not
supported. The memory garbage is dumped into the perf data.

Clear the retire latency if the feature is not supported.

Fixes: c87a31093c70 ("perf/x86: Support Retire Latency")
Reported-by: "Bayduraev, Alexey V" <alexey.v.bayduraev@intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: "Bayduraev, Alexey V" <alexey.v.bayduraev@intel.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20240708193336.1192217-4-kan.liang@linux.intel.com
---
 arch/x86/events/intel/ds.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index b9cc520..fa5ea65 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1944,8 +1944,12 @@ static void setup_pebs_adaptive_sample_data(struct perf_event *event,
 	set_linear_ip(regs, basic->ip);
 	regs->flags = PERF_EFLAGS_EXACT;
 
-	if ((sample_type & PERF_SAMPLE_WEIGHT_STRUCT) && (x86_pmu.flags & PMU_FL_RETIRE_LATENCY))
-		data->weight.var3_w = format_size >> PEBS_RETIRE_LATENCY_OFFSET & PEBS_LATENCY_MASK;
+	if (sample_type & PERF_SAMPLE_WEIGHT_STRUCT) {
+		if (x86_pmu.flags & PMU_FL_RETIRE_LATENCY)
+			data->weight.var3_w = format_size >> PEBS_RETIRE_LATENCY_OFFSET & PEBS_LATENCY_MASK;
+		else
+			data->weight.var3_w = 0;
+	}
 
 	/*
 	 * The record for MEMINFO is in front of GP