From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
Eranian Stephane <eranian@google.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Dapeng Mi <dapeng1.mi@intel.com>, Zide Chen <zide.chen@intel.com>,
Falcon Thomas <thomas.falcon@intel.com>,
Xudong Hao <xudong.hao@intel.com>
Subject: Re: [Patch v2 1/7] perf/x86/intel: Support the 4 new OMR MSRs introduced in DMR and NVL
Date: Tue, 13 Jan 2026 09:22:09 +0800 [thread overview]
Message-ID: <f6c436e4-0d42-45d3-a183-749d9662993b@linux.intel.com> (raw)
In-Reply-To: <20260112102710.GE830755@noisy.programming.kicks-ass.net>
On 1/12/2026 6:27 PM, Peter Zijlstra wrote:
> On Mon, Jan 12, 2026 at 01:16:43PM +0800, Dapeng Mi wrote:
>
>> ISE link: https://www.intel.com/content/www/us/en/content-details/869288/intel-architecture-instruction-set-extensions-programming-reference.html
> Does intel guarantee this link is stable? If not, it is not appropriate
> to stick in a changelog that will live 'forever'.
Maybe not. I suppose it's good enough to put the ISE link into cover
letter. I would remove the ISE link from the commit messages.
>
>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 1840ca1918d1..6ea3260f6422 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -3532,17 +3532,28 @@ static int intel_alt_er(struct cpu_hw_events *cpuc,
>> struct extra_reg *extra_regs = hybrid(cpuc->pmu, extra_regs);
>> int alt_idx = idx;
>>
>> - if (!(x86_pmu.flags & PMU_FL_HAS_RSP_1))
>> - return idx;
>> -
>> - if (idx == EXTRA_REG_RSP_0)
>> - alt_idx = EXTRA_REG_RSP_1;
>> -
>> - if (idx == EXTRA_REG_RSP_1)
>> - alt_idx = EXTRA_REG_RSP_0;
>> + if (idx == EXTRA_REG_RSP_0 || idx == EXTRA_REG_RSP_1) {
>> + if (!(x86_pmu.flags & PMU_FL_HAS_RSP_1))
>> + return idx;
>> + if (++alt_idx > EXTRA_REG_RSP_1)
>> + alt_idx = EXTRA_REG_RSP_0;
>> + if (config & ~extra_regs[alt_idx].valid_mask)
>> + return idx;
>> + }
>>
>> - if (config & ~extra_regs[alt_idx].valid_mask)
>> - return idx;
>> + if (idx >= EXTRA_REG_OMR_0 && idx <= EXTRA_REG_OMR_3) {
>> + if (!(x86_pmu.flags & PMU_FL_HAS_OMR))
>> + return idx;
>> + if (++alt_idx > EXTRA_REG_OMR_3)
>> + alt_idx = EXTRA_REG_OMR_0;
>> + /*
>> + * Subtracting EXTRA_REG_OMR_0 ensures to get correct
>> + * OMR extra_reg entries which start from 0.
>> + */
>> + if (config &
>> + ~extra_regs[alt_idx - EXTRA_REG_OMR_0].valid_mask)
>> + return idx;
>> + }
>>
>> return alt_idx;
>> }
>> @@ -3550,16 +3561,24 @@ static int intel_alt_er(struct cpu_hw_events *cpuc,
>> static void intel_fixup_er(struct perf_event *event, int idx)
>> {
>> struct extra_reg *extra_regs = hybrid(event->pmu, extra_regs);
>> - event->hw.extra_reg.idx = idx;
>> + int er_idx;
>>
>> - if (idx == EXTRA_REG_RSP_0) {
>> - event->hw.config &= ~INTEL_ARCH_EVENT_MASK;
>> - event->hw.config |= extra_regs[EXTRA_REG_RSP_0].event;
>> - event->hw.extra_reg.reg = MSR_OFFCORE_RSP_0;
>> - } else if (idx == EXTRA_REG_RSP_1) {
>> + event->hw.extra_reg.idx = idx;
>> + switch (idx) {
>> + case EXTRA_REG_RSP_0 ... EXTRA_REG_RSP_1:
>> + er_idx = idx - EXTRA_REG_RSP_0;
>> event->hw.config &= ~INTEL_ARCH_EVENT_MASK;
>> - event->hw.config |= extra_regs[EXTRA_REG_RSP_1].event;
>> - event->hw.extra_reg.reg = MSR_OFFCORE_RSP_1;
>> + event->hw.config |= extra_regs[er_idx].event;
>> + event->hw.extra_reg.reg = MSR_OFFCORE_RSP_0 + er_idx;
>> + break;
>> + case EXTRA_REG_OMR_0 ... EXTRA_REG_OMR_3:
>> + er_idx = idx - EXTRA_REG_OMR_0;
>> + event->hw.config &= ~ARCH_PERFMON_EVENTSEL_UMASK;
>> + event->hw.config |= 1ULL << (8 + er_idx);
>> + event->hw.extra_reg.reg = MSR_OMR_0 + er_idx;
>> + break;
>> + default:
>> + pr_warn("The extra reg idx %d is not supported.\n", idx);
>> }
>> }
> I found it jarring to have these two functions so dissimilar; I've
> changed both to be a switch statement.
>
> ---
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -3532,16 +3532,17 @@ static int intel_alt_er(struct cpu_hw_ev
> struct extra_reg *extra_regs = hybrid(cpuc->pmu, extra_regs);
> int alt_idx = idx;
>
> - if (idx == EXTRA_REG_RSP_0 || idx == EXTRA_REG_RSP_1) {
> + switch (idx) {
> + case EXTRA_REG_RSP_0 ... EXTRA_REG_RSP_1:
> if (!(x86_pmu.flags & PMU_FL_HAS_RSP_1))
> return idx;
> if (++alt_idx > EXTRA_REG_RSP_1)
> alt_idx = EXTRA_REG_RSP_0;
> if (config & ~extra_regs[alt_idx].valid_mask)
> return idx;
> - }
> + break;
>
> - if (idx >= EXTRA_REG_OMR_0 && idx <= EXTRA_REG_OMR_3) {
> + case EXTRA_REG_OMR_0 ... EXTRA_REG_OMR_3:
> if (!(x86_pmu.flags & PMU_FL_HAS_OMR))
> return idx;
> if (++alt_idx > EXTRA_REG_OMR_3)
> @@ -3550,9 +3551,12 @@ static int intel_alt_er(struct cpu_hw_ev
> * Subtracting EXTRA_REG_OMR_0 ensures to get correct
> * OMR extra_reg entries which start from 0.
> */
> - if (config &
> - ~extra_regs[alt_idx - EXTRA_REG_OMR_0].valid_mask)
> + if (config & ~extra_regs[alt_idx - EXTRA_REG_OMR_0].valid_mask)
> return idx;
> + break;
> +
> + default:
> + break;
> }
>
> return alt_idx;
> @@ -3571,12 +3575,14 @@ static void intel_fixup_er(struct perf_e
> event->hw.config |= extra_regs[er_idx].event;
> event->hw.extra_reg.reg = MSR_OFFCORE_RSP_0 + er_idx;
> break;
> +
> case EXTRA_REG_OMR_0 ... EXTRA_REG_OMR_3:
> er_idx = idx - EXTRA_REG_OMR_0;
> event->hw.config &= ~ARCH_PERFMON_EVENTSEL_UMASK;
> event->hw.config |= 1ULL << (8 + er_idx);
> event->hw.extra_reg.reg = MSR_OMR_0 + er_idx;
> break;
> +
> default:
> pr_warn("The extra reg idx %d is not supported.\n", idx);
> }
Yeah, this looks prettier. Would change it.
next prev parent reply other threads:[~2026-01-13 1:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 5:16 [Patch v2 0/7] Enable core PMU for DMR and NVL Dapeng Mi
2026-01-12 5:16 ` [Patch v2 1/7] perf/x86/intel: Support the 4 new OMR MSRs introduced in " Dapeng Mi
2026-01-12 10:27 ` Peter Zijlstra
2026-01-13 1:22 ` Mi, Dapeng [this message]
2026-01-12 5:16 ` [Patch v2 2/7] perf/x86/intel: Add support for PEBS memory auxiliary info field in DMR Dapeng Mi
2026-01-12 5:16 ` [Patch v2 3/7] perf/x86/intel: Add core PMU support for DMR Dapeng Mi
2026-01-12 10:41 ` Peter Zijlstra
2026-01-13 1:59 ` Mi, Dapeng
2026-01-12 5:16 ` [Patch v2 4/7] perf/x86/intel: Add support for PEBS memory auxiliary info field in NVL Dapeng Mi
2026-01-12 5:16 ` [Patch v2 5/7] perf/x86/intel: Add core PMU support for Novalake Dapeng Mi
2026-01-12 5:16 ` [Patch v2 6/7] perf/x86: Use macros to replace magic numbers in attr_rdpmc Dapeng Mi
2026-01-12 5:16 ` [Patch v2 7/7] perf/x86/intel: Add support for rdpmc user disable feature Dapeng Mi
2026-01-12 10:57 ` Peter Zijlstra
2026-01-13 2:29 ` Mi, Dapeng
2026-01-13 10:51 ` Peter Zijlstra
2026-01-13 1:49 ` Ian Rogers
2026-01-13 2:49 ` Mi, Dapeng
2026-03-10 0:04 ` Ian Rogers
2026-03-10 5:28 ` 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=f6c436e4-0d42-45d3-a183-749d9662993b@linux.intel.com \
--to=dapeng1.mi@linux.intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dapeng1.mi@intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=thomas.falcon@intel.com \
--cc=xudong.hao@intel.com \
--cc=zide.chen@intel.com \
/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