linux-stable.git/arch/x86/kernel/cpu/cacheinfo.c, branch linux-rolling-stable

x86/cpu/cacheinfo: Simplify cacheinfo_amd_init_llc_id() using _cpuid4_info

2025-09-17T09:22:40+00:00

struct _cpuid4_info has the same layout as the CPUID leaf 0x8000001d.
Use the encoded definition and amd_fill_cpuid4_info(), get_cache_id()
helpers instead of open coding masks and shifts to calculate the llc_id.

cacheinfo_amd_init_llc_id() is only called on AMD systems that support
X86_FEATURE_TOPOEXT and amd_fill_cpuid4_info() uses the information from
CPUID leaf 0x8000001d on all these systems which is consistent with the
current open coded implementation.

While at it, avoid reading  cpu_data() every time get_cache_id() is
called and instead pass the APIC ID necessary to return the
_cpuid4_info.id from get_cache_id().

No functional changes intended.

  [ bp: do what Ahmed suggests: merge into one patch, make id4 ptr
    const. ]

Signed-off-by: K Prateek Nayak 
Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Ingo Molnar 
Acked-by: Ahmed S. Darwish 
Link: https://lore.kernel.org/20250821051910.7351-2-kprateek.nayak@amd.com

x86/cacheinfo: Rename CPUID(0x2) descriptors iterator parameter

2025-05-16T08:49:55+00:00

The CPUID(0x2) descriptors iterator has been renamed from:

    for_each_leaf_0x2_entry()

to:

    for_each_cpuid_0x2_desc()

since it iterates over CPUID(0x2) cache and TLB "descriptors", not
"entries".

In the macro's x86/cacheinfo call-site, rename the parameter denoting the
parsed descriptor at each iteration from 'entry' to 'desc'.

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Andrew Cooper 
Cc: John Ogness 
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250508150240.172915-7-darwi@linutronix.de

x86/cpuid: Rename cpuid_get_leaf_0x2_regs() to cpuid_leaf_0x2()

2025-05-16T08:49:48+00:00

Rename the CPUID(0x2) register accessor function:

    cpuid_get_leaf_0x2_regs(regs)

to:

    cpuid_leaf_0x2(regs)

for consistency with other  accessors that return full CPUID
registers outputs like:

    cpuid_leaf(regs)
    cpuid_subleaf(regs)

In the same vein, rename the CPUID(0x2) iteration macro:

    for_each_leaf_0x2_entry()

to:

    for_each_cpuid_0x2_desc()

to include "cpuid" in the macro name, and since what is iterated upon is
CPUID(0x2) cache and TLB "descriptos", not "entries".  Prefix an
underscore to that iterator macro parameters, so that the newly renamed
'desc' parameter do not get mixed with "union leaf_0x2_regs :: desc[]" in
the macro's implementation.

Adjust all the affected call-sites accordingly.

While at it, use "CPUID(0x2)" instead of "CPUID leaf 0x2" as this is the
recommended style.

No change in functionality intended.

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Andrew Cooper 
Cc: John Ogness 
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250508150240.172915-6-darwi@linutronix.de

x86/cpuid: Set as the main CPUID header

2025-05-15T16:23:55+00:00

The main CPUID header  was originally a storefront for the
headers:

    
    

Now that the latter CPUID(0x2) header has been merged into the former,
there is no practical difference between  and
.

Migrate all users to the  header, in preparation of
the removal of .

Don't remove  just yet, in case some new code in -next
started using it.

Suggested-by: Ingo Molnar 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: Andrew Cooper 
Cc: H. Peter Anvin 
Cc: John Ogness 
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250508150240.172915-3-darwi@linutronix.de

x86/platform/amd: Move the header to

2025-04-14T07:34:14+00:00

Collect AMD specific platform header files in .

Signed-off-by: Ingo Molnar 
Acked-by: Borislav Petkov (AMD) 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Mario Limonciello 
Link: https://lore.kernel.org/r/20250413084144.3746608-4-mingo@kernel.org

x86/cacheinfo: Standardize header files and CPUID references

2025-04-11T09:14:55+00:00

Reference header files using their canonical form .

Standardize on CPUID(0xN), instead of CPUID(N), for all standard leaves.
This removes ambiguity and aligns them with their extended counterparts
like CPUID(0x8000001d).

References: 0dd09e215a39 ("x86/cacheinfo: Apply maintainer-tip coding style fixes")
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: Andrew Cooper 
Cc: "H. Peter Anvin" 
Cc: John Ogness 
Link: https://lore.kernel.org/r/20250411070401.1358760-3-darwi@linutronix.de

x86/cacheinfo: Properly parse CPUID(0x80000006) L2/L3 associativity

2025-04-09T18:47:05+00:00

Complete the AMD CPUID(4) emulation logic, which uses CPUID(0x80000006)
for L2/L3 cache info and an assocs[] associativity mapping array, by
adding entries for 3-way caches and 6-way caches.

Properly handle the case where CPUID(0x80000006) returns an L2/L3
associativity of 9.  This is not real associativity, but a marker to
indicate that the respective L2/L3 cache information should be retrieved
from CPUID(0x8000001d) instead.  If such a marker is encountered, return
early from legacy_amd_cpuid4(), thus effectively emulating an "invalid
index" CPUID(4) response with a cache type of zero.

When checking if CPUID(0x80000006) L2/L3 cache info output is valid, and
given the associtivity marker 9 above, do not just check if the whole
ECX/EDX register is zero.  Rather, check if the associativity is zero or
9.  An associativity of zero implies no L2/L3 cache, which make it the
more correct check anyway vs. a zero check of the whole output register.

Fixes: a326e948c538 ("x86, cacheinfo: Fixup L3 cache information for AMD multi-node processors")
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: Andrew Cooper 
Cc: "H. Peter Anvin" 
Cc: John Ogness 
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250409122233.1058601-3-darwi@linutronix.de

x86/cacheinfo: Properly parse CPUID(0x80000005) L1d/L1i associativity

2025-04-09T18:47:05+00:00

For the AMD CPUID(4) emulation cache info logic, the same associativity
mapping array, assocs[], is used for both CPUID(0x80000005) and
CPUID(0x80000006).

This is incorrect since per the AMD manuals, the mappings for
CPUID(0x80000005) L1d/L1i associativity is:

   n = 0x1 -> 0xfe	n
   n = 0xff		fully associative

while assocs[] maps these values to:

   n = 0x1, 0x2, 0x4	n
   n = 0x3, 0x7, 0x9	0
   n = 0x6		8
   n = 0x8		16
   n = 0xa		32
   n = 0xb		48
   n = 0xc		64
   n = 0xd		96
   n = 0xe		128
   n = 0xf		fully associative

which is only valid for CPUID(0x80000006).

Parse CPUID(0x80000005) L1d/L1i associativity values as shown in the AMD
manuals.  Since the 0xffff literal is used to denote full associativity
at the AMD CPUID(4)-emulation logic, define AMD_CPUID4_FULLY_ASSOCIATIVE
for it instead of spreading that literal in more places.

Mark the assocs[] mapping array as only valid for CPUID(0x80000006) L2/L3
cache information.

Fixes: a326e948c538 ("x86, cacheinfo: Fixup L3 cache information for AMD multi-node processors")
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: Andrew Cooper 
Cc: "H. Peter Anvin" 
Cc: John Ogness 
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250409122233.1058601-2-darwi@linutronix.de

x86/cacheinfo: Apply maintainer-tip coding style fixes

2025-03-25T09:23:37+00:00

The x86/cacheinfo code has been heavily refactored and fleshed out at
parent commits, where any necessary coding style fixes were also done
in place.

Apply Documentation/process/maintainer-tip.rst coding style fixes to the
rest of the code, and align its assignment expressions for readability.

Standardize on CPUID(n) when mentioning leaf queries.

Avoid breaking long lines when doing so helps readability.

At cacheinfo_amd_init_llc_id(), rename variable 'msb' to 'index_msb' as
this is how it's called at the rest of cacheinfo.c code.

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250324133324.23458-30-darwi@linutronix.de

x86/cacheinfo: Introduce cpuid_amd_hygon_has_l3_cache()

2025-03-25T09:23:30+00:00

Multiple code paths at cacheinfo.c and amd_nb.c check for AMD/Hygon CPUs
L3 cache presensce by directly checking leaf 0x80000006 EDX output.

Extract that logic into its own function.  While at it, rework the
AMD/Hygon LLC topology ID caclculation comments for clarity.

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250324133324.23458-29-darwi@linutronix.de