[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141024134800.GC21513@worktop.programming.kicks-ass.net>
Date: Fri, 24 Oct 2014 15:48:00 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
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
On Fri, Oct 24, 2014 at 04:18:46PM +0300, Alexander Shishkin wrote:
> Peter Zijlstra <peterz@...radead.org> writes:
> 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.
If you've got hardware that 'exposes' functionality not enumerated in
CPUID you have the capability of modifying the kernel.
And while it might seem like a cute feature when you have early
hardware, that is no reason to make the code horrible. Either just patch
your firmware such that CPUID reports the right bits for your hardware
or frob the kernel.
--
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