linux-kernel - [PATCH v1 0/2] x86/cacheinfo: Fixes for CPUID(0x80000005) and CPUID(0x80000006)

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: <20250409105429.1048199-1-darwi@linutronix.de>
Date: Wed,  9 Apr 2025 12:54:23 +0200
From: "Ahmed S. Darwish" <darwi@...utronix.de>
To: Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	John Ogness <john.ogness@...utronix.de>,
	x86@...nel.org,
	x86-cpuid@...ts.linux.dev,
	LKML <linux-kernel@...r.kernel.org>,
	"Ahmed S. Darwish" <darwi@...utronix.de>
Subject: [PATCH v1 0/2] x86/cacheinfo: Fixes for CPUID(0x80000005) and CPUID(0x80000006)

Hi,

While working on the x86-cpuid-db CPUID model on top of the CPUID(2) and
CPUID(4) cleanups at tip/x86/cpu,[*] I've discovered some L1/2/3 cache
associativity parsing issues for the AMD CPUID(4) emulation logic .

Here are the fixes on top of -rc1.

* Summary:

The AMD CPUID(4) emulation logic, uses CPUID(0x80000005) and
CPUID(0x80000006) for extracting the L1/L2/L3 cache info.  It then uses
an assocs[] associativity mapping array to map the extracted
associativity values to their CPUID(4) equivalents.

Using the same associativity mapping array for both leaves is invalid.

Per the AMD manuals, the associativity field semantics between
CPUID(0x80000005) and CPUID(0x80000006) is different.  The first patch
fixes that for the former leaf.  For the latter leaf, the second patch
completes the associativity mapping array and handles the special case of
an L2/L3 associativity of 9, which is just a marker — not a real cache
associativity value.

* Example testing for L1d cacheinfo:

On a Qemu-emulated AMD machine without CPUID(0x8000001d) topology
extensions, and with below cpuid(1) view:

   L1 data cache information (0x80000005/ecx):
      line size (bytes) = 0x40 (64)
      lines per tag     = 0x1 (1)
      associativity     = 0x8 (8)
      size (KB)         = 0x20 (32)
   L1 instruction cache information (0x80000005/edx):
      line size (bytes) = 0x40 (64)
      lines per tag     = 0x1 (1)
      associativity     = 0x4 (4)
      size (KB)         = 0x40 (64)
   L2 unified cache information (0x80000006/ecx):
      line size (bytes) = 0x40 (64)
      lines per tag     = 0x1 (1)
      associativity     = 8-way (6)
      size (KB)         = 0x200 (512)
   L3 cache information (0x80000006/edx):
      line size (bytes)     = 0x40 (64)
      lines per tag         = 0x1 (1)
      associativity         = 16-way (8)
      size (in 512KB units) = 0x10 (16)

Before applying this PQ, we get:

   /sys/devices/system/cpu/cpu[0-8]/cache/index0/ways_of_associativity: 16
   /sys/devices/system/cpu/cpu[0-8]/cache/index0/number_of_sets: 32

and after:

   /sys/devices/system/cpu/cpu[0-8]/cache/index0/ways_of_associativity: 8
   /sys/devices/system/cpu/cpu[0-8]/cache/index0/number_of_sets: 64

Thanks,

[*] https://lore.kernel.org/lkml/20250304085152.51092-1-darwi@linutronix.de
    https://lore.kernel.org/lkml/20250324133324.23458-1-darwi@linutronix.de

8<--

Ahmed S. Darwish (2):
  x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity
  x86/cacheinfo: Properly parse CPUID(0x80000006) L2/L3 associativity

 arch/x86/kernel/cpu/cacheinfo.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
--
2.49.0