[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sifen2d5.fsf@ashishki-desk.ger.corp.intel.com>
Date: Tue, 13 Jan 2015 17:09:58 +0200
From: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
Robert Richter <rric@...nel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Mike Galbraith <efault@....de>,
Paul Mackerras <paulus@...ba.org>,
Stephane Eranian <eranian@...gle.com>,
Andi Kleen <ak@...ux.intel.com>, kan.liang@...el.com,
adrian.hunter@...el.com, markus.t.metzger@...el.com,
mathieu.poirier@...aro.org, acme@...radead.org
Subject: Re: [PATCH v8 12/14] x86: perf: intel_pt: Intel PT PMU driver
Peter Zijlstra <peterz@...radead.org> writes:
> On Fri, Nov 14, 2014 at 03:43:45PM +0200, Alexander Shishkin wrote:
>> +static void pt_event_stop(struct perf_event *event, int mode)
>> +{
>> + struct pt *pt = this_cpu_ptr(&pt_ctx);
>> +
>> + ACCESS_ONCE(pt->handle_nmi) = 0;
>
> Why is this needed? Will the hardware still generate interrupts if you
> stop the PT thing?
Actually, it turns out that the interrupt condition can race with the
wrmsr that disables tracing and the PT bit remains set in the global
status register, causing the next PMI to go into the PT PMI handler,
which then may decide to re-enable the counter that should be disabled.
Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists