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: <85588439-ec0e-4824-8193-f0737880ecb9@linux.intel.com>
Date: Mon, 27 Jan 2025 10:19:34 -0500
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Andi Kleen <ak@...ux.intel.com>, Dapeng Mi <dapeng1.mi@...ux.intel.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Ian Rogers <irogers@...gle.com>,
 Adrian Hunter <adrian.hunter@...el.com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Eranian Stephane <eranian@...gle.com>, linux-kernel@...r.kernel.org,
 linux-perf-users@...r.kernel.org, Dapeng Mi <dapeng1.mi@...el.com>
Subject: Re: [PATCH 03/20] perf/x86/intel: Parse CPUID archPerfmonExt leaves
 for non-hybrid CPUs



On 2025-01-23 1:58 p.m., Andi Kleen wrote:
>> +	/*
>> +	 * The archPerfmonExt (0x23) includes an enhanced enumeration of
>> +	 * PMU architectural features with a per-core view. For non-hybrid,
>> +	 * each core has the same PMU capabilities. It's good enough to
>> +	 * update the x86_pmu from the booting CPU. For hybrid, the x86_pmu
>> +	 * is used to keep the common capabilities. Still keep the values
>> +	 * from the leaf 0xa. The core specific update will be done later
>> +	 * when a new type is online.
>> +	 */
>> +	if (!is_hybrid() && boot_cpu_has(X86_FEATURE_ARCH_PERFMON_EXT))
>> +		update_pmu_cap(NULL);
> 
> It seems ugly to have these different code paths. Couldn't non hybrid
> use x86_pmu in the same way? I assume it would be a larger patch.

The current non-hybrid is initialized in the intel_pmu_init(). But some
of the initialization code for the hybrid is in the
intel_pmu_cpu_starting(). Yes, it's better to move it together. It
should be a larger patch. Since it's impacted other features, a separate
patch set should be required.

Thanks,
Kan


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ