From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752692AbcDUTRN (ORCPT ); Thu, 21 Apr 2016 15:17:13 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:44181 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752004AbcDUTRM (ORCPT ); Thu, 21 Apr 2016 15:17:12 -0400 Date: Thu, 21 Apr 2016 21:17:02 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: Borislav Petkov , Alexander Shishkin , Ingo Molnar , linux-kernel@vger.kernel.org, vince@deater.net, eranian@google.com, Arnaldo Carvalho de Melo , Mathieu Poirier Subject: Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits Message-ID: <20160421191702.GL3430@twins.programming.kicks-ass.net> References: <1461251823-12416-1-git-send-email-alexander.shishkin@linux.intel.com> <1461251823-12416-3-git-send-email-alexander.shishkin@linux.intel.com> <20160421174813.GA29639@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 21, 2016 at 08:55:38PM +0200, Thomas Gleixner wrote: > On Thu, 21 Apr 2016, Borislav Petkov wrote: > > > +#define MSR_IA32_RTIT_ADDR0_A 0x00000580 > > > +#define MSR_IA32_RTIT_ADDR0_B 0x00000581 > > > +#define MSR_IA32_RTIT_ADDR1_A 0x00000582 > > > +#define MSR_IA32_RTIT_ADDR1_B 0x00000583 > > > +#define MSR_IA32_RTIT_ADDR2_A 0x00000584 > > > +#define MSR_IA32_RTIT_ADDR2_B 0x00000585 > > > +#define MSR_IA32_RTIT_ADDR3_A 0x00000586 > > > +#define MSR_IA32_RTIT_ADDR3_B 0x00000587 > > > > So can we not turn msr-index.h a dumping ground for MSRs pls? > > > > If those are only PT-relevant, why not define them all in pt.h? > > I have to disagree here. The MSRs itself can really go into msr-index.h while > the bit definitions might go elsewhere. What's wrong with having all MSRs at a > central place? So I agree with Thomas; the risk of not doing this is that we'll introduce the same MSR again, in another file, under another name. That's confusion we can do without.