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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ba407b6-a108-41ce-b1b2-3c03aa25d272@intel.com>
Date: Wed, 12 Nov 2025 12:07:07 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Kaushlendra Kumar <kaushlendra.kumar@...el.com>, mingo@...hat.com,
 acme@...nel.org, namhyung@...nel.org, jolsa@...nel.org,
 adrian.hunter@...el.com, bp@...en8.de, dave.hansen@...ux.intel.com,
 x86@...nel.org
Cc: linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/events/intel/cstate: Add Pantherlake support

On 11/12/25 01:00, Kaushlendra Kumar wrote:
> It supports the same C-state residency counters as Lunarlake.This
> enables monitoring of C1, C6, C7 core states and C2,C3,C6,C10
> package states residency counters on Pantherlake platforms.

Is this actually documented? Or is there just a smoke-filled room at
Intel somewhere where this is decided?

> diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
> index ec753e39b007..b3582eeb6c4b 100644
> --- a/arch/x86/events/intel/cstate.c
> +++ b/arch/x86/events/intel/cstate.c
> @@ -41,7 +41,7 @@
>   *	MSR_CORE_C1_RES: CORE C1 Residency Counter
>   *			 perf code: 0x00
>   *			 Available model: SLM,AMT,GLM,CNL,ICX,TNT,ADL,RPL
> - *					  MTL,SRF,GRR,ARL,LNL
> + *					  MTL,SRF,GRR,ARL,LNL,PTL

Could we get rid of these, please?

Folks can 100% figure this out from the data structures themselves.
Unless there's a compelling reason, this is pure churn.

> @@ -652,6 +653,7 @@ static const struct x86_cpu_id intel_cstates_match[] __initconst = {
>  	X86_MATCH_VFM(INTEL_ARROWLAKE_H,	&adl_cstates),
>  	X86_MATCH_VFM(INTEL_ARROWLAKE_U,	&adl_cstates),
>  	X86_MATCH_VFM(INTEL_LUNARLAKE_M,	&lnl_cstates),
> +	X86_MATCH_VFM(INTEL_PANTHERLAKE_L,	&lnl_cstates),
>  	{ },
>  };
>  MODULE_DEVICE_TABLE(x86cpu, intel_cstates_match);
Also, why *can't* this just be enumerated?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ