Messages in this thread | | | From | Alexander Shishkin <> | Subject | Re: [PATCH v5 12/20] x86: perf: intel_pt: Intel PT PMU driver | Date | Fri, 24 Oct 2014 15:01:49 +0300 |
| |
Peter Zijlstra <peterz@infradead.org> writes:
> 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.
I can't pretend to understand the logic behind this either.
> 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.
Agreed.
Regards, -- Alex
| |