Messages in this thread | | | Date | Fri, 24 Oct 2014 13:26:10 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v5 12/20] x86: perf: intel_pt: Intel PT PMU driver |
| |
On Fri, Oct 24, 2014 at 10:49:33AM +0300, Alexander Shishkin wrote: > Peter Zijlstra <peterz@infradead.org> writes: > > > On Mon, Oct 13, 2014 at 04:45:40PM +0300, Alexander Shishkin wrote: > >> +++ b/arch/x86/kernel/cpu/perf_event_intel.c > >> @@ -1528,6 +1528,14 @@ again: > >> } > >> > >> /* > >> + * Intel PT > >> + */ > >> + if (__test_and_clear_bit(55, (unsigned long *)&status)) { > >> + handled++; > >> + intel_pt_interrupt(); > >> + } > >> + > > > > How does the PT interrupt interact with the regular PMI? In particular > > does it respect stuff like FREEZE_ON_PMI etc? > > It ignores the FREEZE_ON_PMI bit. I stop it by hand inside the PMI > handler, so you can see parts of the handler in the trace if you're > tracing the kernel.
Urgh, horrid that. Routing something to the same interrupt, sharing status registers but not observing the same semantics for the interrupt is a massive fail.
IIRC Andi was planning to start using FREEZE_ON_PMI to avoid the MSR writes in intel_pmu_{disable,enable}_all(), this interrupt not actually respecting that makes that non-trivial.
We already use FREEZE_ON_PMI for LBR, but for now PT and LBR are mutually exclusive so that's not a problem, if we ever get those working together this needs to get fixed.
| |