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]
Date:   Fri, 6 Jan 2023 06:05:41 +0000
From:   "Zhang, Rui" <rui.zhang@...el.com>
To:     "bp@...en8.de" <bp@...en8.de>
CC:     "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

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.

thanks,
rui

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ