linux-kernel - Re: [PATCH V3 1/6] perf/x86/intel/uncore: Add Sapphire Rapids server support

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:   Wed, 30 Jun 2021 08:56:10 -0400
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
        linux-kernel@...r.kernel.org, eranian@...gle.com,
        namhyung@...nel.org, jolsa@...hat.com, ak@...ux.intel.com,
        yao.jin@...ux.intel.com
Subject: Re: [PATCH V3 1/6] perf/x86/intel/uncore: Add Sapphire Rapids server
 support



On 6/30/2021 5:36 AM, Greg KH wrote:
> On Tue, Jun 29, 2021 at 11:13:58AM -0700, kan.liang@...ux.intel.com wrote:
>> From: Kan Liang <kan.liang@...ux.intel.com>
>>
>> Intel Sapphire Rapids supports a discovery mechanism, that allows an
>> uncore driver to discover the different components ("boxes") of the
>> chip.
>>
>> All the generic information of the uncore boxes should be retrieved from
>> the discovery tables. This has been enabled with the commit edae1f06c2cd
>> ("perf/x86/intel/uncore: Parse uncore discovery tables"). Add
>> use_discovery to indicate the case. The uncore driver doesn't need to
>> hard code the generic information for each uncore box.
>>
>> But we still need to enable various functionality that cannot be
>> directly discovered. This is done here.
>>   - Add a meaningful name for each uncore block.
>>   - Add CHA filter support.
>>   - The layout of the control registers for each uncore block is a little
>>     bit different from the generic one. Set the platform specific format
>>     and ops. Expose the common ops which can be reused.
>>   - Add a fixed counter for IMC
>>
>> All the undiscovered platform-specific features are hard code in the
>> spr_uncores[]. Add uncore_type_customized_copy(), instead of the memcpy,
>> to only overwrite these features.
>>
>> Only the uncore blocks which are inculded in the discovery tables are
>> enabled here. Other uncore blocks, e.g., free-running counters, will be
>> supported in the following patch.
>>
>> Signed-off-by: Kan Liang <kan.liang@...ux.intel.com>
>> ---
> 
> Why is there no other intel.com review on this before sending it out?
> 

For the perf related code, currently I follow a loose internal review 
process. Before posting any patches to LKML, I start an internal review 
process by sending the patches to an internal mailing list. People 
(mainly Andi) will review the patches and give some comments.
After several rounds of reviews, the reviewers may give a reviewed-by 
tag or just keep silent. I usually wait for several days. If there is no 
objection, I will post the patches in LKML for further review. That's 
why some patches have a reviewed-by, some doesn't in this patchset.
But for the patches which you are the key maintainer, I followed the 
standard internal review process. As you can see, the reviewed-by from 
Rafael is tagged in the first patch of V1.

Please let me know if you'd like me to follow the standard internal 
review process in the future.

Thanks,
Kan