Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Fri, 6 Jan 2023 11:14:17 +0100
From:   Ingo Molnar <mingo@kernel.org>
To:     "Zhang, Rui" <rui.zhang@intel.com>
Cc:     "bp@alien8.de" <bp@alien8.de>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "ak@linux.intel.com" <ak@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "kan.liang@linux.intel.com" <kan.liang@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] perf/x86/rapl: Add support for Intel Meteor Lake
Message-ID: <Y7f0eRI++oXvWlrM@gmail.com>
References: <20230104145831.25498-1-rui.zhang@intel.com>
 <25d07838-3904-a086-4238-f56c9424b53a@intel.com>
 <ea9186869cca50a21efcc1a9cc4dbe5adcd1784b.camel@intel.com>
 <Y7aejeHDpLlwwYbr@zn.tnic>
 <4cc5cd868b20366fc9d4bf157656e0c295074282.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4cc5cd868b20366fc9d4bf157656e0c295074282.camel@intel.com>
Precedence: bulk


* Zhang, Rui <rui.zhang@intel.com> wrote:

> On Thu, 2023-01-05 at 10:55 +0100, Borislav Petkov wrote:
> > On Thu, Jan 05, 2023 at 06:54:31AM +0000, Zhang, Rui wrote:
> > > I thought of this before and got some ideas related.
> > > Say, instead of maintaining the model list in a series of drivers,
> > > can
> > > we have something similar to "cpu_feature" instead?
> > 
> > Yes, you can define a synthetic X86_FEATURE flag and set it for each 
> > CPU model which supports the feature in arch/x86/kernel/cpu/intel.c so 
> > that at least all the model matching gunk is kept where it belongs, in 
> > the CPU init code and the other code simply tests that flag.
> 
> Great, thanks for this info.
> 
> But I still have a question.
>
> Take RAPL feature for example, the feature is not architectural, although 
> 80% of the platforms may follow the same behavior, but there are still 
> cases that behave differently. And so far, there are 8 different 
> behaviors based on different models.
> 
> In this case, can we have several different flags for the RAPL feature 
> and make the RAPL driver probe on different RAPL flags? Or else, a model 
> list is still needed.

Introducing a synthethic CPU flag only makes sense for behavior that is 
near-100% identical among models - ie. if the only thing missing is the 
CPUID enumeration.

If RAPL details are continuously changing among CPU models, with no real 
architected compatibility guarantees, then it probably only makes sense to 
introduce the flag once it's enumerated at the CPUID level as well.

Thanks,

	Ingo