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

x86/tsx: Make tsx_ctrl_state static

2025-10-24T16:24:42+00:00

Move all definitions related to tsx_ctrl_state to tsx.c. They are
never referenced outside this file.

No functional change.

Signed-off-by: Petr Tesarik 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Nikolay Borisov 
Link: https://lore.kernel.org/all/cover.1758906115.git.ptesarik@suse.com

x86/cacheinfo: Move AMD cache_disable_0/1 handling to separate file

2025-03-25T09:22:39+00:00

Parent commit decoupled amd_northbridge out of _cpuid4_info_regs, where
it was merely "parked" there until ci_info_init() can store it in the
private pointer of the  API.

Given that decoupling, move the AMD-specific L3 cache_disable_0/1 sysfs
code from the generic (and already extremely convoluted) x86/cacheinfo
code into its own file.

Compile the file only if CONFIG_AMD_NB and CONFIG_SYSFS are both
enabled, which mirrors the existing logic.

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-14-darwi@linutronix.de

x86/cpu: Remove unused TLB strings

2025-03-04T10:17:33+00:00

Commit:

  e0ba94f14f74 ("x86/tlb_info: get last level TLB entry number of CPU")

added the TLB table for parsing CPUID(0x4), including strings
describing them. The string entry in the table was never used.

Convert them to comments.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20250304085152.51092-10-darwi@linutronix.de

x86/topology/intel: Unlock CPUID before evaluating anything

2024-05-31T18:25:56+00:00

Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
this bit is set by the BIOS then CPUID evaluation including topology
enumeration does not work correctly as the evaluation code does not try
to analyze any leaf greater than two.

This went unnoticed before because the original topology code just
repeated evaluation several times and managed to overwrite the initial
limited information with the correct one later. The new evaluation code
does it once and therefore ends up with the limited and wrong
information.

Cure this by unlocking CPUID right before evaluating anything which
depends on the maximum CPUID leaf being greater than two instead of
rereading stuff after unlock.

Fixes: 22d63660c35e ("x86/cpu: Use common topology code for Intel")
Reported-by: Peter Schneider 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov (AMD) 
Tested-by: Peter Schneider 
Cc: 
Link: https://lore.kernel.org/r/fd3f73dc-a86f-4bcf-9c60-43556a21eb42@googlemail.com

x86/cpu: Use common topology code for HYGON

2024-02-15T21:07:38+00:00

Switch it over to use the consolidated topology evaluation and remove the
temporary safe guards which are not longer needed.

No functional change intended.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Zhang Rui 
Tested-by: Wang Wendy 
Tested-by: K Prateek Nayak 
Link: https://lore.kernel.org/r/20240212153625.207750409@linutronix.de

x86/cpu: Provide an AMD/HYGON specific topology parser

2024-02-15T21:07:37+00:00

AMD/HYGON uses various methods for topology evaluation:

  - Leaf 0x80000008 and 0x8000001e based with an optional leaf 0xb,
    which is the preferred variant for modern CPUs.

    Leaf 0xb will be superseded by leaf 0x80000026 soon, which is just
    another variant of the Intel 0x1f leaf for whatever reasons.
    
  - Subleaf 0x80000008 and NODEID_MSR base

  - Legacy fallback

That code is following the principle of random bits and pieces all over the
place which results in multiple evaluations and impenetrable code flows in
the same way as the Intel parsing did.

Provide a sane implementation by clearly separating the three variants and
bringing them in the proper preference order in one place.

This provides the parsing for both AMD and HYGON because there is no point
in having a separate HYGON parser which only differs by 3 lines of
code. Any further divergence between AMD and HYGON can be handled in
different functions, while still sharing the existing parsers.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Zhang Rui 
Tested-by: Wang Wendy 
Tested-by: K Prateek Nayak 
Link: https://lore.kernel.org/r/20240212153625.020038641@linutronix.de

x86/cpu: Use common topology code for Intel

2024-02-15T21:07:37+00:00

Intel CPUs use either topology leaf 0xb/0x1f evaluation or the legacy
SMP/HT evaluation based on CPUID leaf 0x1/0x4.

Move it over to the consolidated topology code and remove the random
topology hacks which are sprinkled into the Intel and the common code.

No functional change intended.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Zhang Rui 
Tested-by: Wang Wendy 
Tested-by: K Prateek Nayak 
Link: https://lore.kernel.org/r/20240212153624.893644349@linutronix.de

x86/cpu: Provide cpu_init/parse_topology()

2024-02-15T21:07:36+00:00

Topology evaluation is a complete disaster and impenetrable mess. It's
scattered all over the place with some vendor implementations doing early
evaluation and some not. The most horrific part is the permanent
overwriting of smt_max_siblings and __max_die_per_package, instead of
establishing them once on the boot CPU and validating the result on the
APs.

The goals are:

  - One topology evaluation entry point

  - Proper sharing of pointlessly duplicated code

  - Proper structuring of the evaluation logic and preferences.

  - Evaluating important system wide information only once on the boot CPU

  - Making the 0xb/0x1f leaf parsing less convoluted and actually fixing
    the short comings of leaf 0x1f evaluation.

Start to consolidate the topology evaluation code by providing the entry
points for the early boot CPU evaluation and for the final parsing on the
boot CPU and the APs.

Move the trivial pieces into that new code:

   - The initialization of cpuinfo_x86::topo

   - The evaluation of CPUID leaf 1, which presets topo::initial_apicid

   - topo_apicid is set to topo::initial_apicid when invoked from early
     boot. When invoked for the final evaluation on the boot CPU it reads
     the actual APIC ID, which makes apic_get_initial_apicid() obsolete
     once everything is converted over.

Provide a temporary helper function topo_converted() which shields off the
not yet converted CPU vendors from invoking code which would break them.
This shielding covers all vendor CPUs which support SMP, but not the
historical pure UP ones as they only need the topology info init and
eventually the initial APIC initialization.

Provide two new members in cpuinfo_x86::topo to store the maximum number of
SMT siblings and the number of dies per package and add them to the debugfs
readout. These two members will be used to populate this information on the
boot CPU and to validate the APs against it.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Peter Zijlstra (Intel) 
Tested-by: Zhang Rui 
Tested-by: Wang Wendy 
Tested-by: K Prateek Nayak 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20240212153624.581436579@linutronix.de

x86/cpu: Move cpu_l[l2]c_id into topology info

2023-10-10T12:38:18+00:00

The topology IDs which identify the LLC and L2 domains clearly belong to
the per CPU topology information.

Move them into cpuinfo_x86::cpuinfo_topo and get rid of the extra per CPU
data and the related exports.

This also paves the way to do proper topology evaluation during early boot
because it removes the only per CPU dependency for that.

No functional change.

Signed-off-by: Thomas Gleixner 
Tested-by: Juergen Gross 
Tested-by: Sohil Mehta 
Tested-by: Michael Kelley 
Tested-by: Peter Zijlstra (Intel) 
Tested-by: Zhang Rui 
Reviewed-by: Arjan van de Ven 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20230814085112.803864641@linutronix.de

x86/speculation: Add Gather Data Sampling mitigation

2023-07-19T23:45:37+00:00

Gather Data Sampling (GDS) is a hardware vulnerability which allows
unprivileged speculative access to data which was previously stored in
vector registers.

Intel processors that support AVX2 and AVX512 have gather instructions
that fetch non-contiguous data elements from memory. On vulnerable
hardware, when a gather instruction is transiently executed and
encounters a fault, stale data from architectural or internal vector
registers may get transiently stored to the destination vector
register allowing an attacker to infer the stale data using typical
side channel techniques like cache timing attacks.

This mitigation is different from many earlier ones for two reasons.
First, it is enabled by default and a bit must be set to *DISABLE* it.
This is the opposite of normal mitigation polarity. This means GDS can
be mitigated simply by updating microcode and leaving the new control
bit alone.

Second, GDS has a "lock" bit. This lock bit is there because the
mitigation affects the hardware security features KeyLocker and SGX.
It needs to be enabled and *STAY* enabled for these features to be
mitigated against GDS.

The mitigation is enabled in the microcode by default. Disable it by
setting gather_data_sampling=off or by disabling all mitigations with
mitigations=off. The mitigation status can be checked by reading:

    /sys/devices/system/cpu/vulnerabilities/gather_data_sampling

Signed-off-by: Daniel Sneddon 
Signed-off-by: Dave Hansen 
Acked-by: Josh Poimboeuf