linux-kernel - Re: [PATCH v5 12/20] x86: perf: intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Oct 2014 16:18:46 +0300
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, acme@...radead.org
Subject: Re: [PATCH v5 12/20] x86: perf: intel_pt: Intel PT PMU driver

Peter Zijlstra <peterz@...radead.org> writes:

> On Fri, Oct 24, 2014 at 03:13:19PM +0300, Alexander Shishkin wrote:
>> Peter Zijlstra <peterz@...radead.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
--
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/