linux-rng/arch/x86/kernel/acpi, branch master

Merge tag 'x86_cpu_for_v7.3_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-19T02:09:42Z

Pull x86 cpuid updates from Borislav Petkov: - Get rid of static_cpu_has() - one less API to care about testing CPU features - Unify the handling of CPU core types (performance, efficient, etc) by mapping the vendor-specific types to Linux ones - Continuation of the work of Ahmed Darwish to centralize CPUID leaf representation * tag 'x86_cpu_for_v7.3_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/CPU: Rename struct cpuid_read_output to struct cpuid_output x86/cpu/scattered: Sort it properly x86/cpu: Use parsed CPUID(0x1) x86/lib: Add CPUID(0x1) family and model calculation x86/cpu: Use parsed CPUID(0x0) x86/cpu/transmeta: Rescan CPUID(0x1) after modifying capabilities x86/topology: Add TOPO_CPU_TYPE_LOW_POWER x86/topology: Name the AMD core-type values x86/topo: Map vendor CPU types to generic Linux such types x86/bugs: Don't use cpu-type matching in cpu_vuln_blacklist x86/cpu: Hide and rename static_cpu_has()

x86/topology: Add TOPO_CPU_TYPE_LOW_POWER

2026-07-23T21:23:47Z

AMD heterogeneous parts report a third core type via CPUID Fn0x80000026 EBX[31:28] (Extended CPU Topology, Core Type): 0 - Performance 1 - Efficiency 2 - Low Power get_topology_cpu_type() only translates the first two, so on parts that ship low-power cores the third type falls through to TOPO_CPU_TYPE_UNKNOWN. Add TOPO_CPU_TYPE_LOW_POWER which takes care of this new type. [ bp: Massage commit message, zap the "what" explanation. ] Signed-off-by: Vishal Badole Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20260721154514.2506972-4-Vishal.Badole@amd.com

x86/topo: Map vendor CPU types to generic Linux such types

2026-07-23T21:23:15Z

Sashiko reported¹ that a confusion could ensue if a vendor-specific CPU type 0 (performance) gets attempted to be used in a x86_cpu_id match table. The current logic treats 0 as the wildcard X86_CPU_TYPE_ANY and such a thing would end up matching the wrong CPUs. This is all backwards because we started using the vendor-specific CPU type number instead of using a Linux-defined, generic CPU type which is agnostic. Convert the current logic to it before users start appearing. ¹https://sashiko.dev/#/patchset/20260629094349.533301-1-Vishal.Badole%40amd.com Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Vishal Badole Link: https://patch.msgid.link/20260721154514.2506972-2-Vishal.Badole@amd.com

acpi: Stop using 32-bit MSR interfaces

2026-07-17T08:26:50Z

The 32-bit MSR interfaces rdmsr(), wrmsr(), rdmsr_safe() and wrmsr_safe() are planned to be removed. Use the related 64-bit variants instead. In processor_throttling.c drop needless initializers. Signed-off-by: Juergen Gross Signed-off-by: Ingo Molnar Acked-by: Rafael J. Wysocki (Intel) Link: https://patch.msgid.link/20260629060526.3638272-5-jgross@suse.com

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

2026-05-28T20:01:25Z

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:25Z

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:19Z

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:15Z

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:21Z

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:03Z

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