From: Sandipan Das <sandipan.das@amd.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 2/3] perf/x86: Move MSR_CORE_PERF_GLOBAL_* dump to vendor code
Date: Mon, 17 Aug 2026 10:45:46 +0530 [thread overview]
Message-ID: <86d5a3e9-4002-4f67-a1b0-6596fb58a68a@amd.com> (raw)
In-Reply-To: <20260814180140.5F9BB1F00A3A@smtp.kernel.org>
On 14-08-2026 23:31, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Unintended removal of MSR_IA32_DEBUGCTLMSR from AMD PMU debug dump.
> --
>
> --- Patch [2]: [PATCH v2 2/3] perf/x86: Move MSR_CORE_PERF_GLOBAL_* dump to vendor code ---
> commit 9c3227849508af744eb4359d394119d9f9ee749a
> Author: Sandipan Das <sandipan.das@amd.com>
>
> perf/x86: Move MSR_CORE_PERF_GLOBAL_* dump to vendor code
>
> This commit moves the dumping of MSR_CORE_PERF_GLOBAL_* and
> MSR_ARCH_PERFMON_FIXED_CTR_CTRL registers from common code to vendor-specific
> code. This prevents unchecked MSR access errors on AMD processors that report
> PerfMonV2 support but lack these Intel Architectural PerfMon registers.
>
> Closes: https://lore.kernel.org/all/20260717150315.2868314-1-ptesarik@suse.com/
>
>> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
>> index ae773f8d55c39..4c70cb0148716 100644
>> --- a/arch/x86/events/core.c
>> +++ b/arch/x86/events/core.c
>
> [ ... ]
>
>> @@ -1561,38 +1561,15 @@ static void x86_pmu_start(struct perf_event *event, int flags)
>>
>> void x86_pmu_print_debug(int cpu)
>> {
>> - u64 ctrl, status, overflow, pmc_ctrl, pmc_count, prev_left, fixed;
>> unsigned long *cntr_mask, *fixed_cntr_mask;
>> - struct event_constraint *pebs_constraints;
>> + u64 pmc_ctrl, pmc_count, prev_left;
>> struct cpu_hw_events *cpuc;
>> - u64 pebs, debugctl;
>> int idx;
>>
>> cpuc = &per_cpu(cpu_hw_events, cpu);
>> cntr_mask = hybrid(cpuc->pmu, cntr_mask);
>> fixed_cntr_mask = hybrid(cpuc->pmu, fixed_cntr_mask);
>> - pebs_constraints = hybrid(cpuc->pmu, pebs_constraints);
>> -
>> - if (x86_pmu.version >= 2) {
>> - rdmsrq(MSR_CORE_PERF_GLOBAL_CTRL, ctrl);
>> - rdmsrq(MSR_CORE_PERF_GLOBAL_STATUS, status);
>> - rdmsrq(MSR_CORE_PERF_GLOBAL_OVF_CTRL, overflow);
>> - 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 (pebs_constraints) {
>> - rdmsrq(MSR_IA32_PEBS_ENABLE, pebs);
>> - pr_info("CPU#%d: pebs: %016llx\n", cpu, pebs);
>> - }
>> - if (x86_pmu.lbr_nr) {
>> - rdmsrq(MSR_IA32_DEBUGCTLMSR, debugctl);
>> - pr_info("CPU#%d: debugctl: %016llx\n", cpu, debugctl);
>> - }
>
> [Severity: Medium]
> Will this unintentionally drop the MSR_IA32_DEBUGCTLMSR dump for AMD CPUs?
>
> AMD processors with LBR support use MSR_IA32_DEBUGCTLMSR for LBR freezing, but
> since this read was moved entirely to the Intel-specific intel_pmu_print_debug(),
> SysRq-P will no longer dump this register for AMD processors relying on the
> common x86_pmu_print_debug() function.
>
> Should the debugctl dump be preserved in common code, or added to an AMD-specific
> print_debug function?
>
If the intent is to just see if LBR is enabled, then amd_pmu_v2_print_debug()
already does that by dumping MSR_AMD_DBG_EXTN_CFG. I am not sure it matters
here whether freeze is enabled as well.
>> - }
>> +
>> pr_info("CPU#%d: active: %016llx\n", cpu, *(u64 *)cpuc->active_mask);
>>
>> for_each_set_bit(idx, cntr_mask, X86_PMC_IDX_MAX) {
>
next prev parent reply other threads:[~2026-08-17 5:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 17:48 [PATCH v2 0/3] perf/x86: Fix perf_event_print_debug() on non-Intel PMUs Sandipan Das
2026-08-14 17:48 ` [PATCH v2 1/3] perf/x86: Add x86_pmu::print_debug Sandipan Das
2026-08-14 18:01 ` sashiko-bot
2026-08-14 17:48 ` [PATCH v2 2/3] perf/x86: Move MSR_CORE_PERF_GLOBAL_* dump to vendor code Sandipan Das
2026-08-14 18:01 ` sashiko-bot
2026-08-17 5:15 ` Sandipan Das [this message]
2026-08-14 17:48 ` [PATCH v2 3/3] perf/x86/amd: Implement x86_pmu::print_debug Sandipan Das
2026-08-14 17:56 ` sashiko-bot
2026-08-17 1:12 ` [PATCH v2 0/3] perf/x86: Fix perf_event_print_debug() on non-Intel PMUs Mi, Dapeng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86d5a3e9-4002-4f67-a1b0-6596fb58a68a@amd.com \
--to=sandipan.das@amd.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox