linux-kernel - Re: [PATCH 1/2] perf/x86/rapl: Add support for Intel Meteor Lake

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]

Message-ID: <Y7f+UqN5qqfJUeoy@gmail.com>
Date:   Fri, 6 Jan 2023 11:56:18 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "Zhang, Rui" <rui.zhang@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "kan.liang@...ux.intel.com" <kan.liang@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] perf/x86/rapl: Add support for Intel Meteor Lake


* Borislav Petkov <bp@...en8.de> wrote:

> On Fri, Jan 06, 2023 at 06:05:41AM +0000, Zhang, Rui wrote:
> > 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.
> 
> Well, you asked about detecting CPUs supporting RAPL.
> 
> Now you're asking about different RAPL "subfunctionality" or whatever.
> 
> You could do the synthetic flag for feature detection because apparently 
> giving it a CPUID flag is soo expensive (/sarcastic eyeroll) and then you 
> can pick apart subfeatures in the RAPL code and do flags there, away from 
> the x86 arch code because no one should see that.

It's a trade-off in any case: there's a point where quirk flags or even 
feature flags become harder to read and harder to maintain than cleanly 
separated per model driver functions.

Especially if internally at Intel RAPL functionality is not yet treated as 
an 'architected' feature, and new aspects are added in a less disciplined 
fashion ...

Sometimes the addition of an 'architected' CPU feature iterates the 
feature-set non-trivially - as people consider it a last-minute chance to 
get in their favorite features without having to deal with backwards 
compatibility ...

So I'm somewhat pessimistically leaning towards the current status quo of 
per model enumeration. Would be glad to be proven wrong too. :-)

Thanks,

	Ingo