Re: [PATCH 1/1] perf/x86: Do not read fixed counter control register if there is none
Sandipan Das <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.perf.user |
|---|---|
| Message-ID | <[email protected]> |
On 03-08-2026 14:27, Petr Tesarik wrote: > On Mon, 20 Jul 2026 14:57:25 +0530 > Sandipan Das <[email protected]> wrote: > >> On 17-07-2026 20:33, Petr Tesarik wrote: >>> [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>> >>> When printing out CPU performance registers for debugging, skip >>> MSR_ARCH_PERFMON_FIXED_CTR_CTRL if fixed counters are not implemented. >>> >>> Since AMD CPUs with PerMonV2 do not implement this register, attempts to >>> read it generate a #GP. In particular, SysRq-P logs something like this: >>> >>> [ 14.748144] [ T1118] sysrq: Show Regs >>> [ 14.748896] [ T1118] unchecked MSR access error: RDMSR from 0x38d at rIP: 0xffffffff937154c6 (native_read_msr+0x6/0x40) >>> [ 14.750878] [ T1118] Call Trace: >>> [ 14.751505] [ T1118] <TASK> >>> [ 14.752057] [ T1118] paravirt_read_msr+0x7/0x10 >>> [ 14.752940] [ T1118] perf_event_print_debug+0x135/0x240 >>> [ 14.753931] [ T1118] __handle_sysrq.cold+0x9b/0xde >>> [ 14.754855] [ T1118] write_sysrq_trigger+0x59/0x80 >>> [ 14.755779] [ T1118] proc_reg_write+0x5a/0xb0 >>> [ 14.756631] [ T1118] vfs_write+0xce/0x430 >>> [ 14.757406] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.758322] [ T1118] ? security_file_fcntl+0x5f/0x120 >>> [ 14.759083] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.759754] [ T1118] ? __x64_sys_fcntl+0x80/0x110 >>> [ 14.760334] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.761005] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.761676] [ T1118] ? __ct_user_enter+0x27/0xc0 >>> [ 14.762270] [ T1118] ksys_write+0x6a/0xe0 >>> [ 14.762776] [ T1118] do_syscall_64+0xe1/0x610 >>> [ 14.763324] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.763995] [ T1118] ? __ct_user_enter+0x27/0xc0 >>> [ 14.764564] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.765233] [ T1118] ? do_syscall_64+0x205/0x610 >>> [ 14.765806] [ T1118] ? __x64_sys_ioctl+0x97/0xe0 >>> [ 14.766375] [ T1118] ? __pfx_woken_wake_function+0x10/0x10 >>> [ 14.767048] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.767717] [ T1118] ? get_close_on_exec+0x34/0x40 >>> [ 14.768311] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.768985] [ T1118] ? do_fcntl+0x6da/0x8e0 >>> [ 14.769502] [ T1118] ? do_syscall_64+0x205/0x610 >>> [ 14.770083] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.772321] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.773166] [ T1118] ? tty_read+0x150/0x220 >>> [ 14.773722] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.774423] [ T1118] ? filp_flush+0x5b/0x80 >>> [ 14.774966] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.775660] [ T1118] ? filp_close+0x25/0x40 >>> [ 14.776214] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.776936] [ T1118] ? do_dup2+0xae/0x140 >>> [ 14.777486] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.778309] [ T1118] ? ksys_dup3+0x67/0xf0 >>> [ 14.778870] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.779600] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.780310] [ T1118] ? __ct_user_enter+0x27/0xc0 >>> [ 14.780917] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.781613] [ T1118] ? do_syscall_64+0x205/0x610 >>> [ 14.782215] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.782907] [ T1118] ? ksys_read+0x6a/0xe0 >>> [ 14.783429] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.784120] [ T1118] ? __ct_user_enter+0x27/0xc0 >>> [ 14.784741] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.785431] [ T1118] ? __ct_user_exit+0x15/0xb0 >>> [ 14.786014] [ T1118] ? srso_alias_return_thunk+0x5/0xfbef5 >>> [ 14.786706] [ T1118] ? do_syscall_64+0x98/0x610 >>> [ 14.787282] [ T1118] ? exc_page_fault+0x6d/0x180 >>> [ 14.787873] [ T1118] entry_SYSCALL_64_after_hwframe+0x76/0x7e >>> [ 14.788612] [ T1118] RIP: 0033:0x7f70d6497e0a >>> [ 14.789186] [ T1118] Code: 08 03 00 00 59 5e 48 83 f8 fc 75 1e 83 e2 39 83 fa 08 75 16 e8 05 ff ff ff 0f 1f 80 00 00 00 00 49 89 ca 48 8b 44 24 20 0f 05 <48> 83 c4 18 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f >>> [ 14.791587] [ T1118] RSP: 002b:00007ffc36a93580 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 >>> [ 14.792617] [ T1118] RAX: ffffffffffffffda RBX: 00007f70d65f6580 RCX: 00007f70d6497e0a >>> [ 14.793594] [ T1118] RDX: 0000000000000002 RSI: 0000556f34e41c30 RDI: 0000000000000001 >>> [ 14.794574] [ T1118] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 >>> [ 14.795563] [ T1118] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002 >>> [ 14.796537] [ T1118] R13: 0000556f34e41c30 R14: 0000000000000001 R15: 0000000000000000 >>> [ 14.797514] [ T1118] </TASK> >>> >>> Signed-off-by: Petr Tesarik <[email protected]> >>> --- >>> arch/x86/events/core.c | 7 +++++-- >>> 1 file changed, 5 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c >>> index d1af33d96d0a3..8310bedfc364f 100644 >>> --- a/arch/x86/events/core.c >>> +++ b/arch/x86/events/core.c >>> @@ -1581,13 +1581,16 @@ void perf_event_print_debug(void) >>> rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL, ctrl); >>> rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status); >>> rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, overflow); >> >> GLOBAL_{CTRL,STATUS,OVF_CTRL} functionality is also provided via different MSRs >> for AMD PMU version 2 and I assume that reading the ones above will also raise >> #GPs. If they don't, the reported values will surely be incorrect. > > They do not raise #GPs on my Ryzen 7 system, but that's about the only > system I have tried. Perhaps it is based on Zen 3 or older where x86_pmu.version is set to 0. > > Honetly, I was very unsure about the availability of the feauture(s) > and what the appropriate checks would be; that was the reason to > include you as a recipient. What is the AMD-recommended method to check > whether a CPU supports global perf control MSRs? Does x86.pmu_version > even work? If yes, should I then simply make the actual MSR numbers > conditional on AMD/Intel? > > Any guidance welcome. > AMD processors with X86_FEATURE_PERFMON_V2 also set x86_pmu.version to 2. I think that it is better to move the parts that require the use of vendor-specific MSRs to a new callback implemented in arch/x86/events/{intel,amd,zhaoxin}/* instead of making additions to perf_event_print_debug(). I'm also not sure why MSR_CORE_PERF_GLOBAL_OVF_CTRL is read here because this as well as its AMD counterpart, MSR_AMD64_PERF_CNTR_GLOBAL_STATUS_CLR, are both write-only MSRs. Mind if I send a cleanup? > >> >>> - rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL, fixed); >>> >>> pr_info("\n"); >>> pr_info("CPU#%d: ctrl: %016llx\n", cpu, ctrl); >>> pr_info("CPU#%d: status: %016llx\n", cpu, status); >>> pr_info("CPU#%d: overflow: %016llx\n", cpu, overflow); >>> - pr_info("CPU#%d: fixed: %016llx\n", cpu, fixed); >>> + >>> + if (x86_pmu.fixedctr) { >>> + rdmsrq(MSR_ARCH_PERFMON_FIXED_CTR_CTRL, fixed); >>> + pr_info("CPU#%d: fixed: %016llx\n", cpu, fixed); >>> + } >>> if (pebs_constraints) { >>> rdmsrq(MSR_IA32_PEBS_ENABLE, pebs); >>> pr_info("CPU#%d: pebs: %016llx\n", cpu, pebs); >>> -- >>> 2.54.0 >>> >> >