x86/cpu/amd: Enable the fixed Instructions Retired counter IRPERF

Commit aaf248848db50 ("perf/x86/msr: Add AMD IRPERF (Instructions Retired) performance counter") added support for access to the free-running counter via 'perf -e msr/irperf/', but when exercised, we always get a 0 count:

BEFORE:

$ sudo perf stat -e instructions,msr/irperf/ true

Performance counter stats for 'true':

           624,833      instructions
                 0      msr/irperf/

Simply set its enable bit - HWCR bit 30 - to make it start counting.

Enablement is restricted to all machines advertising IRPERF capability, except those susceptible to an erratum that makes the IRPERF return bad values.

That erratum occurs in Family 17h models 00-1fh [1], but not in F17h models 20h and above [2].

AFTER (on a family 17h model 31h machine):

$ sudo perf stat -e instructions,msr/irperf/ true

Performance counter stats for 'true':

           621,690      instructions
           622,490      msr/irperf/

[1] Revision Guide for AMD Family 17h Models 00h-0Fh Processors
[2] Revision Guide for AMD Family 17h Models 30h-3Fh Processors

The revision guides are available from the bugzilla Link below.

---
v3: Removed null stalled cycles per insn from perf example output,
since it got fixed, also address comments from Borislav Petkov:

https://lkml.org/lkml/2020/2/11/395

- rephrase commit text to not say "this patch".
- uploaded both rev. guides (and all public F17h PPRs) to a new "Add AMD x86 documents for future reference" bug, and reference that in a Link: tag.
- rename X86_BUG_AMD_E1054 -> X86_BUG_IRPERF
- add a full stop to a sentence in a comment

v2 got resent, adding Michael Petlan to cc. Original v2:

    https://lore.kernel.org/lkml/[email protected]/

v2: Based on Andi Kleen's review:

https://lore.kernel.org/lkml/[email protected]/

Add an amd_erratum_1054 and use cpu_has_bug infrastructure instead of open-coding the {family,model} check.

 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/include/asm/msr-index.h   |  2 ++
 arch/x86/kernel/cpu/amd.c          | 17 +++++++++++++++++
 3 files changed, 20 insertions(+)

index f3327cb56edf..8979d6fcc79c 100644
@@ -404,5 +404,6 @@
 #define X86_BUG_SWAPGS			X86_BUG(21) /* CPU is affected by speculation through SWAPGS */
 #define X86_BUG_TAA			X86_BUG(22) /* CPU is affected by TSX Async Abort(TAA) */
 #define X86_BUG_ITLB_MULTIHIT		X86_BUG(23) /* CPU may incur MCE during certain page attribute changes */
+#define X86_BUG_IRPERF			X86_BUG(24) /* CPU is affected by Instructions Retired counter Erratum 1054 */
 
 #endif /* _ASM_X86_CPUFEATURES_H */

index ebe1685e92dd..d5e517d1c3dd 100644
@@ -512,6 +512,8 @@
 #define MSR_K7_HWCR			0xc0010015
 #define MSR_K7_HWCR_SMMLOCK_BIT		0
 #define MSR_K7_HWCR_SMMLOCK		BIT_ULL(MSR_K7_HWCR_SMMLOCK_BIT)
+#define MSR_K7_HWCR_IRPERF_EN_BIT	30
+#define MSR_K7_HWCR_IRPERF_EN		BIT_ULL(MSR_K7_HWCR_IRPERF_EN_BIT)
 #define MSR_K7_FID_VID_CTL		0xc0010041
 #define MSR_K7_FID_VID_STATUS		0xc0010042
 

index ac83a0fef628..deebc728e2aa 100644
@@ -28,6 +28,7 @@
 
 static const int amd_erratum_383[];
 static const int amd_erratum_400[];
+static const int amd_erratum_1054[];
 static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);
 
 /*

@@ -694,6 +695,9 @@ static void early_init_amd(struct cpuinfo_x86 *c)
 	if (cpu_has_amd_erratum(c, amd_erratum_400))
 		set_cpu_bug(c, X86_BUG_AMD_E400);
 
+	if (cpu_has_amd_erratum(c, amd_erratum_1054))
+		set_cpu_bug(c, X86_BUG_IRPERF);
+
 	early_detect_mem_encrypt(c);
 
 	/* Re-enable TopologyExtensions if switched off by BIOS */

@@ -972,6 +976,15 @@ static void init_amd(struct cpuinfo_x86 *c)
 	/* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */
 	if (!cpu_has(c, X86_FEATURE_XENPV))
 		set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
+
+	/*
+	 * Turn on the Instructions Retired free counter on machines not
+	 * susceptible to erratum #1054 "Instructions Retired Performance
+	 * Counter May Be Inaccurate".
+	 */
+	if (cpu_has(c, X86_FEATURE_IRPERF) &&
+	    !cpu_has_bug(c, X86_BUG_IRPERF))
+		msr_set_bit(MSR_K7_HWCR, MSR_K7_HWCR_IRPERF_EN_BIT);
 }
 
 #ifdef CONFIG_X86_32

@@ -1099,6 +1112,10 @@ static const int amd_erratum_400[] =
 static const int amd_erratum_383[] =
 	AMD_OSVW_ERRATUM(3, AMD_MODEL_RANGE(0x10, 0, 0, 0xff, 0xf));
 
+/* #1054: Instructions Retired Performance Counter May Be Inaccurate */
+static const int amd_erratum_1054[] =
+	AMD_OSVW_ERRATUM(0, AMD_MODEL_RANGE(0x17, 0, 0, 0x2f, 0xf));
+
 
 static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum)
 {

2.25.0

Hi Borislav,

Yes, that works quite nicely, and saves us a bug bit.

The only reason to have it show in /proc/cpuinfo is for userspace, but they can check for a nonzero count prior to using, instead.

Let me know if you'd like me to send a v4, or if you will just apply this version of yours.

Thanks,

Kim

How is userspace going to check it? perf tool or people *can* check it? If perf is going to check it then I'm fine with having the bug bit in /proc/cpuinfo along with a patch for perf adding usage for it.

If not and people in userspace can maybe check it but they probably won't then adding that bug bit would be a waste of bit.

I can take the simpler version for now. If you still want to have perf tool check the bit, you could submit a new patch adding that bug bit along with a perf tool patch using it...

Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette