Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756644AbaJXNSw (ORCPT ); Fri, 24 Oct 2014 09:18:52 -0400 Received: from mga01.intel.com ([192.55.52.88]:39542 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756401AbaJXNSv (ORCPT ); Fri, 24 Oct 2014 09:18:51 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,780,1406617200"; d="scan'208";a="619819849" From: Alexander Shishkin To: Peter Zijlstra Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Robert Richter , Frederic Weisbecker , Mike Galbraith , Paul Mackerras , Stephane Eranian , Andi Kleen , kan.liang@intel.com, adrian.hunter@intel.com, acme@infradead.org Subject: Re: [PATCH v5 12/20] x86: perf: intel_pt: Intel PT PMU driver In-Reply-To: <20141024130228.GM3219@twins.programming.kicks-ass.net> References: <1413207948-28202-1-git-send-email-alexander.shishkin@linux.intel.com> <1413207948-28202-13-git-send-email-alexander.shishkin@linux.intel.com> <20141022144543.GV12706@worktop.programming.kicks-ass.net> <87tx2t27yb.fsf@ashishki-desk.ger.corp.intel.com> <20141024115131.GY21513@worktop.programming.kicks-ass.net> <87wq7pd5sw.fsf@ashishki-desk.ger.corp.intel.com> <20141024130228.GM3219@twins.programming.kicks-ass.net> User-Agent: Notmuch/0.17+49~gaa57e9d (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Fri, 24 Oct 2014 16:18:46 +0300 Message-ID: <87tx2td2rt.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > On Fri, Oct 24, 2014 at 03:13:19PM +0300, Alexander Shishkin wrote: >> Peter Zijlstra 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/