kernel/linux.git/arch/x86/include/asm/processor.h, branch v7.2-rc1

Merge tag 'x86-cpu-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip

2026-06-15T09:55:17+00:00

Pull x86 cpuid updates from Ingo Molnar: - CPUID API updates (Ahmed S. Darwish): - Introduce a centralized CPUID parser - Introduce a centralized CPUID data model - Introduce - Rename cpuid_leaf()/cpuid_subleaf() APIs - treewide: Explicitly include the x86 CPUID headers - Update to x86-cpuid-db v3.1 (Maciej Wieczor-Retman) - Continued removal of pre-i586 support and related simplifications (Ingo Molnar) - Add Intel CPU model number for rugged Panther Lake (Tony Luck) - Misc fixes, updates and cleanups by Arnd Bergmann, Chao Gao, Lukas Bulwahn, Sohil Mehta, Maciej Wieczor-Retman. * tag 'x86-cpu-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: (25 commits) x86/cpu: Make CONFIG_X86_CX8 unconditional x86/cpu: Remove unused !CONFIG_X86_TSC code x86/cpuid: Update bitfields to x86-cpuid-db v3.1 tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.1 x86/cpu: Make CONFIG_X86_TSC unconditional MAINTAINERS: Drop obsolete FPU EMULATOR section x86/cpu: Fix a F00F bug warning and clean up surrounding code x86/cpu: Add Intel CPU model number for rugged Panther Lake x86/cpuid: Introduce a centralized CPUID parser x86/cpu: Introduce a centralized CPUID data model x86/cpuid: Introduce x86/cpuid: Rename cpuid_leaf()/cpuid_subleaf() APIs x86/cpu: Do not include the CPUID API header in asm/processor.h Documentation: core-api/cpu_hotplug: Remove stale cpu0_hotplug docs x86/cpu, cpufreq: Remove AMD ELAN support x86/fpu: Remove the math-emu/ FPU emulation library x86/fpu: Remove the 'no387' boot option x86/fpu: Remove MATH_EMULATION and related glue code treewide: Explicitly include the x86 CPUID headers x86/cpu: Remove the CONFIG_X86_INVD_BUG quirk ...

Merge tag 'sched-core-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip

2026-06-15T09:20:18+00:00

Pull scheduler updates from Ingo Molnar: "SMP load-balancing updates: - A large series to introduce infrastructure for cache-aware load balancing, with the goal of co-locating tasks that share data within the same Last Level Cache (LLC) domain. By improving cache locality, the scheduler can reduce cache bouncing and cache misses, ultimately improving data access efficiency. Implemented by Chen Yu and Tim Chen, based on early prototype work by Peter Zijlstra, with fixes by Jianyong Wu, Peter Zijlstra and Shrikanth Hegde. - A series to simplify CONFIG_SCHED_SMT ifdef usage (Shrikanth Hegde) Fair scheduler updates: - A series to improve SD_ASYM_CPUCAPACITY scheduling by introducing SMT awareness (Andrea Righi, K Prateek Nayak) - A series to optimize cfs_rq and sched_entity allocation for better data locality (Zecheng Li) - A preparatory series to change fair/cgroup scheduling to a single runqueue, without the final change (Peter Zijlstra) - Auto-manage ext/fair dl_server bandwidth (Andrea Righi) - Fix cpu_util runnable_avg arithmetic (Hongyan Xia) - Optimize update_tg_load_avg()'s rate-limiting code (Rik van Riel) - Allow account_cfs_rq_runtime() to throttle current hierarchy (K Prateek Nayak) - Update util_est after updating util_avg during dequeue, to fix the util signal update logic, which reduces signal noise (Vincent Guittot) Scheduler topology updates: - Allow multiple domains to claim sched_domain_shared (K Prateek Nayak) - Add parameter to split LLC (Peter Zijlstra) Core scheduler updates: - Use trace_call__() to save a static branch (Gabriele Monaco) Scheduler statistics updates: - Drop now-stale mul_u64_u64_div_u64() cputime over-approximation guard (Nicolas Pitre) Deadline scheduler updates: - Reject debugfs dl_server writes for offline CPUs (Andrea Righi) - Fix replenishment logic for non-deferred servers (Yuri Andriaccio) RT scheduling updates: - Turn RT_PUSH_IPI default off for non PREEMPT_RT (Steven Rostedt) - Update default bandwidth for real-time tasks to 1.0 (Yuri Andriaccio) Proxy scheduling updates: - A series to implement Optimized Donor Migration for Proxy Execution (John Stultz, Peter Zijlstra) - Various proxy scheduling cleanups and fixes (Peter Zijlstra, K Prateek Nayak) Misc fixes, improvements and cleanups by Aaron Lu, Andrea Righi, Zenghui Yu, Chen Yu, Guanyou.Chen, John Stultz, Shrikanth Hegde, Peter Zijlstra, Liang Luo and Yiyang Chen" * tag 'sched-core-2026-06-14' of gitolite.kernel.org:pub/scm/linux/kernel/git/tip/tip: (91 commits) sched/fair: Fix newidle vs core-sched sched/deadline: Use task_on_rq_migrating() helper sched/core: Combine separate 'else' and 'if' statements sched/fair: Fix cpu_util runnable_avg arithmetic sched/fair: Unify cfs_rq throttling via account_cfs_rq_runtime() sched/fair: Move the throttled tasks to a local list in tg_unthrottle_up() sched/fair: Call update_curr() before unthrottling the hierarchy sched/fair: Use throttled_csd_list for local unthrottle sched/fair: Convert cfs bandwidth throttling to use guards sched/fair: Allocate cfs_tg_state with percpu allocator sched/fair: Remove task_group->se pointer array sched/fair: Co-locate cfs_rq and sched_entity in cfs_tg_state sched: restore timer_slack_ns when resetting RT policy on fork MAINTAINERS: Fix spelling mistake in Peter's name sched: Simplify ttwu_runnable() sched/proxy: Remove superfluous clear_task_blocked_in() sched/proxy: Remove PROXY_WAKING sched/proxy: Switch proxy to use p->is_blocked sched/proxy: Only return migrate when needed sched: Be more strict about p->is_blocked ...

x86/microcode: Do not access MSR_IA32_PLATFORM_ID when running as a guest

2026-05-26T20:36:23+00:00

Patch in Fixes: causes the usual: unchecked MSR access error: RDMSR from 0x17 at ... (intel_get_platform_id) Call Trace: early_init_intel early_cpu_init setup_arch _printk start_kernel x86_64_start_reservations x86_64_start_kernel common_startup_64 because the kernel is booted in a guest. In order to avoid it, this MSR access needs to be prevented when running virtualized. That is usually done by checking X86_FEATURE_HYPERVISOR but for this particular case it is too early yet. The platform ID needs to be read as early as when microcode is loaded on the BSP: load_ucode_bsp ... -> get_microcode_blob ... -> intel_find_matching_signature and by that time, CPUID leafs haven't been parsed yet. The microcode loader already has logic to check early whether the kernel is running virtualized so make that globally available to arch/x86/. The query whether running virtualized is getting more and more prominent in recent times so might as well make it an arch-global var which the rest of the code can use. Fixes: d8630b67ca1ed ("x86/cpu: Add platform ID to CPU info structure") Reported-by: Vishal Verma Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Binbin Wu Reviewed-by: Xiaoyao Li Tested-by: Binbin Wu Link: https://lore.kernel.org/all/20260430020953.1405535-1-binbin.wu@linux.intel.com

Merge branch 'sched/cache'

2026-05-19T10:18:01+00:00

Merge the cache aware balancer topic branch. # Conflicts: # kernel/sched/topology.c

x86/cpu: Introduce a centralized CPUID data model

2026-05-11T11:09:30+00:00

** Context The x86-cpuid-db project generates a C header file with full C99 bitfield listings for all known CPUID leaf/subleaf query outputs. That header is now merged by parent commits at , and is of the form: struct leaf_0x0_0 { /* CPUID(0x0).0 C99 bitfields */ }; ... struct leaf_0x4_n { /* CPUID(0x4).n C99 bitfields */ }; ... struct leaf_0xd_0 { /* CPUID(0xd).0 C99 bitfields */ }; struct leaf_0xd_1 { /* CPUID(0xd).1 C99 bitfields */ }; struct leaf_0xd_n { /* CPUID(0xd).n C99 bitfields */ }; ... ** Goal Introduce a structured, size-efficient, per-CPU, CPUID data repository. Use the x86-cpuid-db auto-generated data types, and custom CPUID leaf parsers, to build that repository. Given a leaf, subleaf, and index, provide direct memory access to the parsed and cached per-CPU CPUID output. ** Long-term goal Remove the need for drivers and other areas in the kernel to invoke direct CPUID queries. Only one place in the kernel should be allowed to use the CPUID instruction: the CPUID parser code. ** Implementation Introduce CPUID_LEAF()/CPUID_LEAF_N() to build a compact CPUID storage layout in the form: struct leaf_0x0_0 leaf_0x0_0[1]; struct leaf_parse_info leaf_0x0_0_info; struct leaf_0x1_0 leaf_0x1_0[1]; struct leaf_parse_info leaf_0x0_0_info; struct leaf_0x4_n leaf_0x4_n[8]; struct leaf_parse_info leaf_0x4_n_info; ... where each CPUID query stores its output at the designated leaf/subleaf array and has an associated "CPUID query info" structure. Embed the CPUID tables inside "struct cpuinfo_x86" to ensure early-boot and per-CPU access through the CPUs capability structures. Use an array of CPUID output storage entries for each leaf/subleaf combination to accommodate leaves which produce the same output format for a large subleaf range. This is typical for CPUID leaves enumerating hierarchical objects; e.g. CPUID(0x4) cache topology enumeration, CPUID(0xd) XSAVE enumeration, and CPUID(0x12) SGX Enclave Page Cache enumeration. ** New CPUID APIs Assuming a CPU capability structure 'c', provide macros to access the parsed and cached CPUID leaf/subleaf output. These macros resolve to a compile-time tokenization that ensures type-safety: const struct leaf_0x7_0 *l7_0; l7_0 = cpuid_subleaf(c, 0x7, 0); | | └────────┐ | └─────────┐ | * * * &c.cpuid.leaf_0x7_0[0] For CPUID leaves with multiple subleaves having the same output format, provide the APIs: const struct leaf_0x4_n *l4_0, *l4_1; l4_0 = cpuid_subleaf_n(c, 0x4, 0); | | └──────────┐ | └─────────┐ | * * v &c.cpuid.leaf_0x4_n[0] l4_1 = cpuid_subleaf_n(c, 0x4, 1); | | └──────────┐ | └─────────┐ | * * v &c.cpuid.leaf_0x4_n[1] where the indices 0, 1, n above can be passed dynamically; e.g., in an enumeration for loop. Add a clear rationale on why call sites should use the these new APIs instead of directly invoking CPUID. ** Next steps For now, define cached parse entries for CPUID(0x0) and CPUID(0x1). Generic parser logic to fill the CPUID tables, along with more CPUID leaves support, will be added next. Suggested-by: Thomas Gleixner # CPUID data model Suggested-by: Andrew Cooper # x86-cpuid-db schema Suggested-by: Borislav Petkov # Early CPUID centralization drafts Suggested-by: Ingo Molnar # CPUID headers restructuring Suggested-by: Sean Christopherson # cpuid_subleaf_n() APIs Signed-off-by: Ahmed S. Darwish Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/all/20260327021645.555257-1-darwi@linutronix.de Link: https://lore.kernel.org/all/874ixernra.ffs@tglx Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db Link: https://lore.kernel.org/all/aBnSgu_JyEi8fvog@gmail.com Link: https://lore.kernel.org/all/aJ9TbaNMgaplKSbH@google.com

x86/cpu: Do not include the CPUID API header in asm/processor.h

2026-05-08T21:10:10+00:00

asm/processor.h includes asm/cpuid/api.h but it does not need it. Remove the include. This allows the CPUID APIs header to include at a later step without introducing a circular dependency. Note, all call sites which implicitly included the CPUID API through have been modified to explicitly include the CPUID APIs instead. Signed-off-by: Ahmed S. Darwish Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/20260327021645.555257-1-darwi@linutronix.de

x86/topology: Add paramter to split LLC

2026-04-09T13:49:46+00:00

Add a (debug) option to virtually split the LLC, no CAT involved, just fake topology. Used to test code that depends (either in behaviour or directly) on there being multiple LLC domains in a node. Signed-off-by: Peter Zijlstra (Intel)

x86/cpu: Add platform ID to CPU info structure

2026-03-05T20:25:32+00:00

The end goal here is to be able to do x86_match_cpu() and match on a specific platform ID. While it would be possible to stash this ID off somewhere or read it dynamically, that approaches would not be consistent with the other fields which can be matched. Read the platform ID and store it in cpuinfo_x86. There are lots of sites to set this new field. Place it near the place c->microcode is established since the platform ID is so closely intertwined with microcode updates. Note: This should not grow the size of 'struct cpuinfo_x86' in practice since the u8 fits next to another u8 in the structure. Signed-off-by: Dave Hansen Reviewed-by: Sohil Mehta Reviewed-by: Pawan Gupta Link: https://patch.msgid.link/20260304181020.8D518228@davehans-spike.ostc.intel.com

x86/sme: Use percpu boolean to control WBINVD during kexec

2025-09-05T17:40:40+00:00

TL;DR: Prepare to unify how TDX and SME do cache flushing during kexec by making a percpu boolean control whether to do the WBINVD. -- Background -- On SME platforms, dirty cacheline aliases with and without encryption bit can coexist, and the CPU can flush them back to memory in random order. During kexec, the caches must be flushed before jumping to the new kernel otherwise the dirty cachelines could silently corrupt the memory used by the new kernel due to different encryption property. TDX also needs a cache flush during kexec for the same reason. It would be good to have a generic way to flush the cache instead of scattering checks for each feature all around. When SME is enabled, the kernel basically encrypts all memory including the kernel itself and a simple memory write from the kernel could dirty cachelines. Currently, the kernel uses WBINVD to flush the cache for SME during kexec in two places: 1) the one in stop_this_cpu() for all remote CPUs when the kexec-ing CPU stops them; 2) the one in the relocate_kernel() where the kexec-ing CPU jumps to the new kernel. -- Solution -- Unlike SME, TDX can only dirty cachelines when it is used (i.e., when SEAMCALLs are performed). Since there are no more SEAMCALLs after the aforementioned WBINVDs, leverage this for TDX. To unify the approach for SME and TDX, use a percpu boolean to indicate the cache may be in an incoherent state and needs flushing during kexec, and set the boolean for SME. TDX can then leverage it. While SME could use a global flag (since it's enabled at early boot and enabled on all CPUs), the percpu flag fits TDX better: The percpu flag can be set when a CPU makes a SEAMCALL, and cleared when another WBINVD on the CPU obviates the need for a kexec-time WBINVD. Saving kexec-time WBINVD is valuable, because there is an existing race[*] where kexec could proceed while another CPU is active. WBINVD could make this race worse, so it's worth skipping it when possible. -- Side effect to SME -- Today the first WBINVD in the stop_this_cpu() is performed when SME is *supported* by the platform, and the second WBINVD is done in relocate_kernel() when SME is *activated* by the kernel. Make things simple by changing to do the second WBINVD when the platform supports SME. This allows the kernel to simply turn on this percpu boolean when bringing up a CPU by checking whether the platform supports SME. No other functional change intended. [*] The aforementioned race: During kexec native_stop_other_cpus() is called to stop all remote CPUs before jumping to the new kernel. native_stop_other_cpus() firstly sends normal REBOOT vector IPIs to stop remote CPUs and waits them to stop. If that times out, it sends NMI to stop the CPUs that are still alive. The race happens when native_stop_other_cpus() has to send NMIs and could potentially result in the system hang (for more information please see [1]). Signed-off-by: Kai Huang Signed-off-by: Paolo Bonzini Signed-off-by: Dave Hansen Reviewed-by: Tom Lendacky Reviewed-by: Borislav Petkov (AMD) Tested-by: Tom Lendacky Link: https://lore.kernel.org/kvm/b963fcd60abe26c7ec5dc20b42f1a2ebbcc72397.1750934177.git.kai.huang@intel.com/ [1] Link: https://lore.kernel.org/all/20250901160930.1785244-3-pbonzini%40redhat.com

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