linux-stable.git/arch/x86/kernel/acpi, branch master

x86/acpi: Add a helper to get the address of the wakeup mailbox

2026-05-28T20:01:25+00:00

A Hyper-V VTL level 2 guest in a TDX environment needs to map the physical
page of the ACPI Multiprocessor Wakeup Structure as private (encrypted). It
needs to know the physical address of this structure. Add a helper function
to retrieve the address.

Suggested-by: Michael Kelley 
Acked-by: Rafael J. Wysocki (Intel) 
Signed-off-by: Ricardo Neri 
Signed-off-by: Dexuan Cui

x86/acpi: Add functions to setup and access the wakeup mailbox

2026-05-28T20:01:25+00:00

Systems that describe hardware using DeviceTree graphs may enumerate and
implement the wakeup mailbox as defined in the ACPI specification but do
not otherwise depend on ACPI. Expose functions to setup and access the
location of the wakeup mailbox from outside ACPI code.

The function acpi_setup_mp_wakeup_mailbox() stores the physical address of
the mailbox and updates the wakeup_secondary_cpu_64() APIC callback.

The function acpi_madt_multiproc_wakeup_mailbox() returns a pointer to the
mailbox.

Acked-by: Rafael J. Wysocki (Intel) 
Signed-off-by: Ricardo Neri 
Signed-off-by: Dexuan Cui

Revert "ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"

2026-05-08T19:14:19+00:00

Some older systems don't support CPPC in the firmware and this just makes
noise for them when booting.  Drop back to debug.

This reverts commit 21fb59ab4b9767085f4fe1edbdbe3177fbb9ec97.

Fixes: 21fb59ab4b976 ("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn")
Suggested-by: Kim Phillips 
Signed-off-by: Mario Limonciello 
Tested-by: Kim Phillips 
Cc: All applicable 
Link: https://patch.msgid.link/20260504230141.484743-2-mario.limonciello@amd.com
Signed-off-by: Rafael J. Wysocki

x86/acpi: Add acpi_get_cpu_uid() for unified ACPI CPU UID retrieval

2026-04-06T14:55:15+00:00

As a step towards unifying the interface for retrieving ACPI CPU UID
across architectures, introduce a new function acpi_get_cpu_uid() for
x86. While at it, add input validation to make the code more robust.

Update Xen-related code to use acpi_get_cpu_uid() instead of the legacy
cpu_acpi_id() function, and remove the now-unused cpu_acpi_id() to clean
up redundant code.

Signed-off-by: Chengwen Feng 
Reviewed-by: Jonathan Cameron 
Reviewed-by: Juergen Gross 
Link: https://patch.msgid.link/20260401081640.26875-5-fengchengwen@huawei.com
Signed-off-by: Rafael J. Wysocki

x86/acpi: Add acpi=spcr to use SPCR-provided default console

2026-01-17T16:43:21+00:00

The SPCR provided console on x86 is only available as a boot console when
earlycon is provided on the kernel command line, and will not be present in
/proc/consoles.

While it's possible to retain the boot console with the keep_bootcon
parameter, that leaves the console using the less efficient 8250_early driver.

Users wanting to use the firmware suggested console (to avoid maintaining
unique serial console parameters for different server models in large fleets)
with the conventional driver have to parse the kernel log for the console
parameters and reinsert them.

  [    0.005091] ACPI: SPCR 0x000000007FFB5000 000059 (v04 ALASKA A M I    01072009 INTL 20250404)
  [    0.073387] ACPI: SPCR: console: uart,io,0x3f8,115200

In commit

  0231d00082f6 ("ACPI: SPCR: Make SPCR available to x86")¹

the SPCR console was only added as an option for earlycon but not as an
ordinary console so users don't see console output changes.

So users can opt in to an automatic SPCR console, make ACPI init add it if
acpi=spcr is set.

¹https://lore.kernel.org/lkml/20180118150951.28964-1-prarit@redhat.com/

  [ bp: Touchups. ]

Signed-off-by: Shenghao Yang 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://patch.msgid.link/20260117072827.355360-1-me@shenghaoyang.info

x86/acpi/boot: Correct acpi_is_processor_usable() check again

2025-12-14T08:19:03+00:00

ACPI v6.3 defined a new "Online Capable" MADT LAPIC flag. This bit is
used in conjunction with the "Enabled" MADT LAPIC flag to determine if
a CPU can be enabled/hotplugged by the OS after boot.

Before the new bit was defined, the "Enabled" bit was explicitly
described like this (ACPI v6.0 wording provided):

  "If zero, this processor is unusable, and the operating system
  support will not attempt to use it"

This means that CPU hotplug (based on MADT) is not possible. Many BIOS
implementations follow this guidance. They may include LAPIC entries in
MADT for unavailable CPUs, but since these entries are marked with
"Enabled=0" it is expected that the OS will completely ignore these
entries.

However, QEMU will do the same (include entries with "Enabled=0") for
the purpose of allowing CPU hotplug within the guest.

Comment from QEMU function pc_madt_cpu_entry():

  /* ACPI spec says that LAPIC entry for non present
   * CPU may be omitted from MADT or it must be marked
   * as disabled. However omitting non present CPU from
   * MADT breaks hotplug on linux. So possible CPUs
   * should be put in MADT but kept disabled.
   */

Recent Linux topology changes broke the QEMU use case. A following fix
for the QEMU use case broke bare metal topology enumeration.

Rework the Linux MADT LAPIC flags check to allow the QEMU use case only
for guests and to maintain the ACPI spec behavior for bare metal.

Remove an unnecessary check added to fix a bare metal case introduced by
the QEMU "fix".

  [ bp: Change logic as Michal suggested. ]
  [ mingo: Removed misapplied -stable tag. ]

Fixes: fed8d8773b8e ("x86/acpi/boot: Correct acpi_is_processor_usable() check")
Fixes: f0551af02130 ("x86/topology: Ignore non-present APIC IDs in a present package")
Closes: https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmail.com
Reported-by: Michal Pecio 
Signed-off-by: Yazen Ghannam 
Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Ingo Molnar 
Tested-by: Michal Pecio 
Tested-by: Ricardo Neri 
Link: https://lore.kernel.org/20251111145357.4031846-1-yazen.ghannam@amd.com
Cc: stable@vger.kernel.org

Merge tag 'ras_core_for_v6.19_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2025-12-02T19:04:37+00:00

Pull x86 RAS updates from Borislav Petkov:

 - The second part of the AMD MCA interrupts rework after the
   last-minute show-stopper from the last merge window was sorted out.
   After this, the AMD MCA deferred errors, thresholding and corrected
   errors interrupt handlers use common MCA code and are tightly
   integrated into the core MCA code, thereby getting rid of
   considerable duplication. All culminating into allowing CMCI error
   thresholding storms to be detected at AMD too, using the common
   infrastructure

 - Add support for two new MCA bank bits on AMD Zen6 which denote
   whether the error address logged is a system physical address, which
   obviates the need for it to be translated before further error
   recovery can be done

* tag 'ras_core_for_v6.19_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mce: Handle AMD threshold interrupt storms
  x86/mce: Do not clear bank's poll bit in mce_poll_banks on AMD SMCA systems
  x86/mce: Add support for physical address valid bit
  x86/mce: Save and use APEI corrected threshold limit
  x86/mce/amd: Define threshold restart function for banks
  x86/mce/amd: Remove redundant reset_block()
  x86/mce/amd: Support SMCA Corrected Error Interrupt
  x86/mce/amd: Enable interrupt vectors once per-CPU on SMCA systems
  x86/mce: Unify AMD DFR handler with MCA Polling
  x86/mce: Unify AMD THR handler with MCA Polling

x86/mce: Save and use APEI corrected threshold limit

2025-11-21T09:32:28+00:00

The MCA threshold limit generally is not something that needs to change during
runtime. It is common for a system administrator to decide on a policy for
their managed systems.

If MCA thresholding is OS-managed, then the threshold limit must be set at
every boot. However, many systems allow the user to set a value in their BIOS.
And this is reported through an APEI HEST entry even if thresholding is not in
FW-First mode.

Use this value, if available, to set the OS-managed threshold limit.  Users
can still override it through sysfs if desired for testing or debug.

APEI is parsed after MCE is initialized. So reset the thresholding blocks
later to pick up the threshold limit.

Signed-off-by: Yazen Ghannam 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/20251104-wip-mca-updates-v8-0-66c8eacf67b9@amd.com

ACPI: CPPC: Detect preferred core availability on online CPUs

2025-11-07T17:37:42+00:00

Commit 279f838a61f9 ("x86/amd: Detect preferred cores in
amd_get_boost_ratio_numerator()") introduced the ability to detect the
preferred core on AMD platforms by checking if there at least two
distinct highest_perf values.

However, it uses for_each_present_cpu() to iterate through all the
CPUs in the platform, which is problematic when the kernel is booted
with "nosmt=force" commandline option.

Hence limit the search to only the online CPUs.

Fixes: 279f838a61f9 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()")
Reported-by: Christopher Harris 
Closes: https://lore.kernel.org/lkml/CAM+eXpdDT7KjLV0AxEwOLkSJ2QtrsvGvjA2cCHvt1d0k2_C4Cw@mail.gmail.com/
Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" 
Tested-by: Chrisopher Harris 
Signed-off-by: Gautham R. Shenoy 
Link: https://patch.msgid.link/20251107074145.2340-2-gautham.shenoy@amd.com
Signed-off-by: Rafael J. Wysocki

x86/acpi/cstate: Remove open coded check for cpu_feature_enabled()

2025-09-22T17:16:51+00:00

acpi_processor_power_init_bm_check() has an open coded implementation
of cpu_feature_enabled() to detect X86_FEATURE_ZEN.

Switch to using cpu_feature_enabled().

Signed-off-by: Mario Limonciello (AMD) 
Signed-off-by: Rafael J. Wysocki