linux-kernel - [PATCH V2 0/8] Support HBM and CXL PMON uncore counters

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-next>] [day] [month] [year] [list]

Message-Id: <20240614134631.1092359-1-kan.liang@linux.intel.com>
Date: Fri, 14 Jun 2024 06:46:23 -0700
From: kan.liang@...ux.intel.com
To: peterz@...radead.org,
	mingo@...nel.org,
	linux-kernel@...r.kernel.org
Cc: acme@...nel.org,
	namhyung@...nel.org,
	irogers@...gle.com,
	eranian@...gle.com,
	ak@...ux.intel.com,
	yunying.sun@...el.com,
	tim.c.chen@...ux.intel.com,
	Kan Liang <kan.liang@...ux.intel.com>
Subject: [PATCH V2 0/8] Support HBM and CXL PMON uncore counters

From: Kan Liang <kan.liang@...ux.intel.com>

Changes since V2:
- Update the description of patch 1 to explain the design of the new
  RB tree. (Tim)

The uncore PMON information of both HBM and CXL can be retrieved from
the discovery table. However, the CXL entries break the driver's
assumption for the discovery table. The first 7 patches update the
generic support of the discovery table. The last patch enables the HBM
and CXL PMON uncore counters.

The discovery table support was introduced since commit edae1f06c2cd
("perf/x86/intel/uncore: Parse uncore discovery tables"). It's a
self-describing mechanism for the uncore PerfMon hardware. By reading
through an MMIO page worth of information, SW can ‘discover’ all the
standard uncore PMON registers.

The entire discovery table could be big and contain duplicate
information. To save space, the perf uncore driver only stores some key
data. Others are calculated from the key data. The driver further
assumes that the uncore PMON units are symmetric among dies.
So only the unit control addresses on Die 0 are completely stored.
The addresses on other Dies can be calculated via the address of the
first entry on the Die + a fixed offset.

However, it doesn't work for the CXL PMON units. The CXL PMON units
could be asymmetric among Dies. The offset between CXL PMON units may be
different on different Die.

To address the issue, the complete unit control addresses for all
Dies are stored in an RB tree. For a 2-socket EMR, it requires
at most ~6KB extra space, which should be acceptable.

Kan Liang (8):
  perf/x86/uncore: Save the unit control address of all units
  perf/x86/uncore: Support per PMU cpumask
  perf/x86/uncore: Retrieve the unit ID from the unit control RB tree
  perf/x86/uncore: Apply the unit control RB tree to MMIO uncore units
  perf/x86/uncore: Apply the unit control RB tree to MSR uncore units
  perf/x86/uncore: Apply the unit control RB tree to PCI uncore units
  perf/x86/uncore: Cleanup unused unit structure
  perf/x86/intel/uncore: Support HBM and CXL PMON counters

 arch/x86/events/intel/uncore.c           |  97 ++++---
 arch/x86/events/intel/uncore.h           |   8 +-
 arch/x86/events/intel/uncore_discovery.c | 306 +++++++++++++++--------
 arch/x86/events/intel/uncore_discovery.h |  22 +-
 arch/x86/events/intel/uncore_snbep.c     | 128 ++++++++--
 5 files changed, 388 insertions(+), 173 deletions(-)

-- 
2.35.1