Re: [PATCH v5 12/20] x86: perf: intel_pt: Intel PT PMU driver

[Alexander Shishkin <alexander.shishkin@linux.intel.com>]

Peter Zijlstra <peterz@infradead.org> writes:

> On Fri, Oct 24, 2014 at 03:13:19PM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra <peterz@infradead.org> writes:
>> 
>> > On Fri, Oct 24, 2014 at 11:22:20AM +0300, Alexander Shishkin wrote:
>> >> > The fact that the hardware cannot even tell you the supported mask is
>> >> > further fail.
>> >
>> >> The problem with this is that some bits go in groups, there'd be 2..3..4
>> >> bit fields encoding desired packet frequency, for example.
>> >
>> > OK, so put the magic number in the big model array.
>> 
>> I'm not sure I follow. These bits are reserved for the future, they can
>> potentially be whatever combinations of whatever. If we want to probe
>> around for valid combinations is to check everything in the range of
>> 0..2^43 (or something like that, the region reserved for packet enables)
>> and store all the valid ones, which sounds crazy.
>
> I was assuming that the accepted bits are model specific, and we have
> this big model switch statement in perf_event_intel.c:intel_pmu_init(),
> so why not have something like x86_pmu.pt_magic_bitmask = 0xf00d in
> there?

Ah, I see what you mean. The main point of this whole reserved region
proposal is that one shouldn't have to update one's kernel to enable new
PT packets by doing -e intel_pt/config=0xf00d/, if one is CAP_SYS_ADMIN.

> No need to probe in that case. That is the same thing we do for all
> unenumerated model specific things.

They are, actually, enumerated, we just want to be able to enable them
before they are. If the driver is aware of feature X, it can test for it
in CPUID and allow/disallow it based on that.

Regards,
--
Alex