[PATCH v3 0/4] Fix racy and incorrect updates to MSR_K7_HWCR

[Jim Mattson]

I was backporting commit 65f55a301766 ("x86/CPU/AMD: Add CPUID faulting
support") to a local branch based on Linux v6.12, when our internal Sashiko
asked:

> Can this corrupt MSR_K7_HWCR? disable_cpuid()->set_cpuid_faulting() is
> called with preemption disabled, but interrupts are still enabled. Since
> msr_set_bit() performs a read-modify-write without disabling interrupts,
> if an IPI arrives between the read and write and modifies MSR_K7_HWCR
> (e.g. acpi-cpufreq toggling Core Performance Boost), the IPI's update
> will be lost.

To confirm that this wasn't just AI slop, I set up an empirical test on a
Turin system. First, I replaced the amd-pstate cpufreq driver with
acpi-cpufreq. Then I ran a test program, where one thread repeatedly reads
CPU0's HWCR, toggles /sys/devices/system/cpu/cpufreq/boost, reads CPU0's
HWCR again, and then verifies that the CPB_DIS bit has flipped. A second
thread, pinned to CPU0, repeatedly calls arch_prctl(ARCH_SET_CPUID, <val>),
where <val> alternates between 0 and 1. With the second thread running, the
first thread soon fails the verification step, indicating that the CPB_DIS
bit change is, in fact, lost.

Andrew Cooper raised a valid concern regarding the core-scoped nature of
MSR_K7_HWCR on some AMD CPUs. When the MSR is shared between SMT siblings,
a cross-CPU race is possible if SMT threads concurrently modify the
MSR. Centralizing all runtime updates through the amd_update_hwcr() helper
ensures that if explicit serialization is desired, it can be implemented
transparently in a single place. Note that on recent AMD CPUs, the MSR is
thread-scoped.

Google's internal Sashiko highlighted a separate, pre-existing
architectural issue in acpi-cpufreq that Borislav and I briefly touched on:
during shared policy teardown (e.g., driver unload),
acpi_cpufreq_cpu_exit() is only executed for the final CPU in the
policy. As a result, cpufreq_boost_down_prep() only restores the
boost-disable MSR bit on that single CPU, leaving all other sibling CPUs
that shared the policy with the disable bit still set. On Intel platforms,
where the turbo-disable MSR bit acts as a logical OR across the package,
this leaves the entire package permanently boost-disabled after the driver
is unloaded. This issue out of scope for this series, as it requires a
broader redesign of cpufreq policy teardown coordination, and should be
addressed separately.

v2 -> v3:
 - Add WARN_ON_ONCE(in_nmi()) to the helper to ensure NMI safety [Yosry].
 - Redesign amd_update_hwcr() to be a simple bit-based wrapper [Yosry].
 - Fix cpufreq_boost_down_prep() to target the correct CPU via IPI, resolving
   the wrong-CPU update and Intel preemption/migration races [Sashiko].
 - Drop the Fixes tag from patch 4, since the race is now fixed in patch 3.

v2: https://lore.kernel.org/all/20260612215729.1532175-1-jmattson@xxxxxxxxxx/
v1: https://lore.kernel.org/all/20260609211611.466231-1-jmattson@xxxxxxxxxx/

Jim Mattson (4):
  x86/CPU/AMD: Avoid racy updates to MSR_K7_HWCR in set_cpuid_faulting()
  x86/mce/inject: Avoid racy updates to MSR_K7_HWCR during MCE injection
  cpufreq: ACPI: Use IPI to update boost MSR in
    cpufreq_boost_down_prep()
  cpufreq: ACPI: Use amd_update_hwcr() for MSR_K7_HWCR updates

 arch/x86/include/asm/msr-index.h |  2 ++
 arch/x86/include/asm/processor.h |  2 ++
 arch/x86/kernel/cpu/amd.c        | 38 ++++++++++++++++++++++++++
 arch/x86/kernel/cpu/mce/inject.c | 46 ++++++++++----------------------
 arch/x86/kernel/process.c        |  5 +---
 drivers/cpufreq/acpi-cpufreq.c   | 11 ++++----
 6 files changed, 62 insertions(+), 42 deletions(-)


base-commit: 83f1454877cc292b88baf13c829c16ce6937d120