Re: [RESEND PATCH] perf/x86/intel: Fix PEBS-via-PT reload base value for Extended PEBS

From: Peter Zijlstra <peterz@infradead.org>
To: Like Xu <like.xu.linux@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH] perf/x86/intel: Fix PEBS-via-PT reload base value for Extended PEBS
Date: Tue, 22 Jun 2021 15:36:03 +0200	[thread overview]
Message-ID: <YNHnQzECTcFGOoHO@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210621034710.31107-1-likexu@tencent.com>

On Mon, Jun 21, 2021 at 11:47:10AM +0800, Like Xu wrote:
> If we use the "PEBS-via-PT" feature on a platform that supports
> extended PBES, like this:
> 
>     perf record -c 10000 \
>     -e '{intel_pt/branch=0/,branch-instructions/aux-output/p}' uname
> 
> we will encounter the following call trace:
> 
> [  250.906542] unchecked MSR access error: WRMSR to 0x14e1 (tried to write
> 0x0000000000000000) at rIP: 0xffffffff88073624 (native_write_msr+0x4/0x20)
> [  250.920779] Call Trace:
> [  250.923508]  intel_pmu_pebs_enable+0x12c/0x190
> [  250.928359]  intel_pmu_enable_event+0x346/0x390
> [  250.933300]  x86_pmu_start+0x64/0x80
> [  250.937231]  x86_pmu_enable+0x16a/0x2f0
> [  250.941434]  perf_event_exec+0x144/0x4c0
> [  250.945731]  begin_new_exec+0x650/0xbf0
> [  250.949933]  load_elf_binary+0x13e/0x1700
> [  250.954321]  ? lock_acquire+0xc2/0x390
> [  250.958430]  ? bprm_execve+0x34f/0x8a0
> [  250.962544]  ? lock_is_held_type+0xa7/0x120
> [  250.967118]  ? find_held_lock+0x32/0x90
> [  250.971321]  ? sched_clock_cpu+0xc/0xb0
> [  250.975527]  bprm_execve+0x33d/0x8a0
> [  250.979452]  do_execveat_common.isra.0+0x161/0x1d0
> [  250.984673]  __x64_sys_execve+0x33/0x40
> [  250.988877]  do_syscall_64+0x3d/0x80
> [  250.992806]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [  250.998302] RIP: 0033:0x7fbc971d82fb
> [  251.002235] Code: Unable to access opcode bytes at RIP 0x7fbc971d82d1.
> [  251.009303] RSP: 002b:00007fffb8aed808 EFLAGS: 00000202 ORIG_RAX: 000000000000003b
> [  251.017478] RAX: ffffffffffffffda RBX: 00007fffb8af2f00 RCX: 00007fbc971d82fb
> [  251.025187] RDX: 00005574792aac50 RSI: 00007fffb8af2f00 RDI: 00007fffb8aed810
> [  251.032901] RBP: 00007fffb8aed970 R08: 0000000000000020 R09: 00007fbc9725c8b0
> [  251.040613] R10: 6d6c61632f6d6f63 R11: 0000000000000202 R12: 00005574792aac50
> [  251.048327] R13: 00007fffb8af35f0 R14: 00005574792aafdf R15: 00005574792aafe7
> 
> This is because the target reload msr address is calculated
> based on the wrong base msr and the target reload msr value
> is accessed from ds->pebs_event_reset[] with the wrong offset.
> 
> According to Intel SDM Table 2-14, for extended PBES feature,
> the reload msr for MSR_IA32_FIXED_CTRx should be based on
> MSR_RELOAD_FIXED_CTRx.
> 
> For fixed counters, let's fix it by overriding the reload msr
> address and its value, thus avoiding out-of-bounds access.
> 
> Fixes: 42880f726c66("perf/x86/intel: Support PEBS output to PT")
> Signed-off-by: Like Xu <likexu@tencent.com>

Thanks!