[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131219125205.GT3694@twins.programming.kicks-ass.net>
Date: Thu, 19 Dec 2013 13:52:05 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
David Ahern <dsahern@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Jiri Olsa <jolsa@...hat.com>, Mike Galbraith <efault@....de>,
Namhyung Kim <namhyung@...il.com>,
Paul Mackerras <paulus@...ba.org>,
Stephane Eranian <eranian@...gle.com>,
Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH v0 04/71] itrace: Infrastructure for instruction flow
tracing units
Found more:
"Note that no “freezing” takes place with the ToPA PMI. Thus, packet
generation is not frozen, and the interrupt handler will be traced
(though filtering can prevent this). Further, the setting of
IA32_DEBUGCTL.Freeze_Perfmon_on_PMI is ignored and performance counters
are not frozen by a ToPA PMI."
Can someone confirm with the hardware people what happens when an actual
PMU counter overflows and tries to raise the PMI while we're in one that
ignores the 'Freeze_perfmon_on_PMI' bit?
Since you cannot assert an interrupt that already asserted, but that
handler can see the overflow status bit set and will likely process it;
assuming the PMU is actually frozen.
Also, this just smells ripe for errata and ugly bugs.
--
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