summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-25x86/cpu: Use consolidated CPUID leaf 0x2 descriptor tableAhmed S. Darwish
CPUID leaf 0x2 output is a stream of one-byte descriptors, each implying certain details about the CPU's cache and TLB entries. At previous commits, the mapping tables for such descriptors were merged into one consolidated table. The mapping was also transformed into a hash lookup instead of a loop-based lookup for each descriptor. Use the new consolidated table and its hash-based lookup through the for_each_leaf_0x2_tlb_entry() accessor. Remove the TLB-specific mapping, intel_tlb_table[], as it is now no longer used. Remove the <cpuid/types.h> macro, for_each_leaf_0x2_desc(), since the converted code was its last user. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-23-darwi@linutronix.de
2025-03-25x86/cacheinfo: Use consolidated CPUID leaf 0x2 descriptor tableAhmed S. Darwish
CPUID leaf 0x2 output is a stream of one-byte descriptors, each implying certain details about the CPU's cache and TLB entries. At previous commits, the mapping tables for such descriptors were merged into one consolidated table. The mapping was also transformed into a hash lookup instead of a loop-based lookup for each descriptor. Use the new consolidated table and its hash-based lookup through the for_each_leaf_0x2_tlb_entry() accessor. Remove the old cache-specific mapping, cache_table[], as it is no longer used. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-22-darwi@linutronix.de
2025-03-25x86/cpu: Consolidate CPUID leaf 0x2 tablesThomas Gleixner
CPUID leaf 0x2 describes TLBs and caches. So there are two tables with the respective descriptor constants in intel.c and cacheinfo.c. The tables occupy almost 600 byte and require a loop based lookup for each variant. Combining them into one table occupies exactly 1k rodata and allows to get rid of the loop based lookup by just using the descriptor byte provided by CPUID leaf 0x2 as index into the table, which simplifies the code and reduces text size. The conversion of the intel.c and cacheinfo.c code is done separately. [ darwi: Actually define struct leaf_0x2_table. Tab-align all of cpuid_0x2_table[] mapping entries. Define needed SZ_* macros at <linux/sizes.h> instead (merged commit.) Use CACHE_L1_{INST,DATA} as names for L1 cache descriptor types. Set descriptor 0x63 type as TLB_DATA_1G_2M_4M and explain why. Use enums for cache and TLB descriptor types (parent commits.) Start enum types at 1 since type 0 is reserved for unknown descriptors. Ensure that cache and TLB enum type values do not intersect. Add leaf 0x2 table accessor for_each_leaf_0x2_entry() + documentation. ] Co-developed-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-21-darwi@linutronix.de
2025-03-25x86/cpu: Use enums for TLB descriptor typesAhmed S. Darwish
The leaf 0x2 one-byte TLB descriptor types: TLB_INST_4K TLB_INST_4M TLB_INST_2M_4M ... are just discriminators to be used within the intel_tlb_table[] mapping. Their specific values are irrelevant. Use enums for such types. Make the enum packed and static assert that its values remain within a single byte so that the intel_tlb_table[] size do not go out of hand. Use a __CHECKER__ guard for the static_assert(sizeof(enum) == 1) line as sparse ignores the __packed annotation on enums. This is similar to: fe3944fb245a ("fs: Move enum rw_hint into a new header file") for the core SCSI code. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/Z9rsTirs9lLfEPD9@lx-t490 Link: https://lore.kernel.org/r/20250324133324.23458-20-darwi@linutronix.de
2025-03-25x86/cacheinfo: Use enums for cache descriptor typesAhmed S. Darwish
The leaf 0x2 one-byte cache descriptor types: CACHE_L1_INST CACHE_L1_DATA CACHE_L2 CACHE_L3 are just discriminators to be used within the cache_table[] mapping. Their specific values are irrelevant. Use enums for such types. Make the enum packed and static assert that its values remain within a single byte so that the cache_table[] array size do not go out of hand. Use a __CHECKER__ guard for the static_assert(sizeof(enum) == 1) line as sparse ignores the __packed annotation on enums. This is similar to: fe3944fb245a ("fs: Move enum rw_hint into a new header file") for the core SCSI code. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/Z9rsTirs9lLfEPD9@lx-t490 Link: https://lore.kernel.org/r/20250324133324.23458-19-darwi@linutronix.de
2025-03-25x86/cacheinfo: Clarify type markers for CPUID leaf 0x2 cache descriptorsAhmed S. Darwish
CPUID leaf 0x2 output is a stream of one-byte descriptors, each implying certain details about the CPU's cache and TLB entries. Two separate tables exist for interpreting these descriptors: one for TLBs at intel.c and one for caches at cacheinfo.c. These mapping tables will be merged in further commits, among other improvements to their model. In preparation for this, use more descriptive type names for the leaf 0x2 descriptors associated with cpu caches. Namely: LVL_1_INST => CACHE_L1_INST LVL_1_DATA => CACHE_L1_DATA LVL_2 => CACHE_L2 LVL_3 => CACHE_L3 After the TLB and cache descriptors mapping tables are merged, this will make it clear that such descriptors correspond to cpu caches. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-18-darwi@linutronix.de
2025-03-25x86/cacheinfo: Rename 'struct _cpuid4_info_regs' to 'struct _cpuid4_info'Ahmed S. Darwish
Parent commits decoupled amd_northbridge from _cpuid4_info_regs, moved AMD L3 northbridge cache_disable_0/1 sysfs code to its own file, and splitted AMD vs. Intel leaf 0x4 handling into: amd_fill_cpuid4_info() intel_fill_cpuid4_info() fill_cpuid4_info() After doing all that, the "_cpuid4_info_regs" name becomes a mouthful. It is also not totally accurate, as the structure holds cpuid4 derived information like cache node ID and size -- not just regs. Rename struct _cpuid4_info_regs to _cpuid4_info. That new name also better matches the AMD/Intel leaf 0x4 functions mentioned above. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-17-darwi@linutronix.de
2025-03-25x86/cacheinfo: Separate Intel and AMD CPUID leaf 0x4 code pathsAhmed S. Darwish
The CPUID leaf 0x4 parsing code at cpuid4_cache_lookup_regs() is ugly and convoluted. It is tangled with multiple nested conditions to handle: * AMD with TOPEXT, or Hygon CPUs via leaf 0x8000001d * Legacy AMD fallback via leaf 0x4 emulation * Intel CPUs via the actual CPUID leaf 0x4 Moreover, AMD L3 northbridge initialization is also awkwardly placed alongside the CPUID calls of the first two scenarios above. Refactor all of that as follows: * Update AMD's leaf 0x4 emulation comment to represent current state * Clearly label the AMD leaf 0x4 emulation function as a fallback * Split AMD/Hygon and Intel code paths into separate functions * Move AMD L3 northbridge initialization out of CPUID leaf 0x4 code, and into populate_cache_leaves() where it belongs. There, ci_info_init() can directly store the initialized object in the private pointer of the <linux/cacheinfo.h> API. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-16-darwi@linutronix.de
2025-03-25x86/cacheinfo: Use sysfs_emit() for sysfs attributes show()Ahmed S. Darwish
Per Documentation/filesystems/sysfs.rst, a sysfs attribute's show() method should only use sysfs_emit() or sysfs_emit_at() when returning values to user space. Use sysfs_emit() for the AMD L3 cache sysfs attributes cache_disable_0, cache_disable_1, and subcaches. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-15-darwi@linutronix.de
2025-03-25x86/cacheinfo: Move AMD cache_disable_0/1 handling to separate fileAhmed S. Darwish
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 <linux/cacheinfo.h> 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 <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-14-darwi@linutronix.de
2025-03-25x86/cacheinfo: Separate amd_northbridge from _cpuid4_info_regsAhmed S. Darwish
'struct _cpuid4_info_regs' is meant to hold the CPUID leaf 0x4 output registers (EAX, EBX, and ECX), as well as derived information such as the cache node ID and size. It also contains a reference to amd_northbridge, which is there only to be "parked" until ci_info_init() can store it in the priv pointer of the <linux/cacheinfo.h> API. That priv pointer is then used by AMD-specific L3 cache_disable_0/1 sysfs attributes. Decouple amd_northbridge from _cpuid4_info_regs and pass it explicitly through the functions at x86/cacheinfo. Doing so clarifies when amd_northbridge is actually needed (AMD-only code) and when it is not (Intel-specific code). It also prepares for moving the AMD-specific L3 cache_disable_0/1 sysfs code into its own file in next commit. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-13-darwi@linutronix.de
2025-03-25x86/cacheinfo: Consolidate AMD/Hygon leaf 0x8000001d callsAhmed S. Darwish
While gathering CPU cache info, CPUID leaf 0x8000001d is invoked in two separate if blocks: one for Hygon CPUs and one for AMDs with topology extensions. After each invocation, amd_init_l3_cache() is called. Merge the two if blocks into a single condition, thus removing the duplicated code. Future commits will expand these if blocks, so combining them now is both cleaner and more maintainable. Note, while at it, remove a useless "better error?" comment that was within the same function since the 2005 commit e2cac78935ff ("[PATCH] x86_64: When running cpuid4 need to run on the correct CPU"). Note, as previously done at commit aec28d852ed2 ("x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>"), standardize on using 'u32' and 'u8' types. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-12-darwi@linutronix.de
2025-03-25x86/cacheinfo: Standardize _cpuid4_info_regs instance namingAhmed S. Darwish
The cacheinfo code frequently uses the output registers from CPUID leaf 0x4. Such registers are cached in 'struct _cpuid4_info_regs', augmented with related information, and are then passed across functions. The naming of these _cpuid4_info_regs instances is confusing at best. Some instances are called "this_leaf", which is vague as "this" lacks context and "leaf" is overly generic given that other CPUID leaves are also processed within cacheinfo. Other _cpuid4_info_regs instances are just called "base", adding further ambiguity. Standardize on id4 for all instances. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-11-darwi@linutronix.de
2025-03-25x86/cacheinfo: Align ci_info_init() assignment expressionsAhmed S. Darwish
The ci_info_init() function initializes 10 members of a 'struct cacheinfo' instance using passed data from CPUID leaf 0x4. Such assignment expressions are difficult to read in their current form. Align them for clarity. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-10-darwi@linutronix.de
2025-03-25x86/cacheinfo: Constify _cpuid4_info_regs instancesAhmed S. Darwish
_cpuid4_info_regs instances are passed through a large number of functions at cacheinfo.c. For clarity, constify the instance parameters where _cpuid4_info_regs is only read from. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-9-darwi@linutronix.de
2025-03-25x86/cacheinfo: Use proper name for cacheinfo instancesThomas Gleixner
The cacheinfo structure defined at <include/linux/cacheinfo.h> is a generic cache info object representation. Calling its instances at x86 cacheinfo.c "leaf" confuses it with a CPUID leaf -- especially that multiple CPUID calls are already sprinkled across that file. Most of such instances also have a redundant "this_" prefix. Rename all of the cacheinfo "this_leaf" instances to just "ci". [ darwi: Move into separate commit and write commit log ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-8-darwi@linutronix.de
2025-03-25x86/cacheinfo: Properly name amd_cpuid4()'s first parameterThomas Gleixner
amd_cpuid4()'s first parameter, "leaf", is not a CPUID leaf as the name implies. Rather, it's an index emulating CPUID(4)'s subleaf semantics; i.e. an ID for the cache object currently enumerated. Rename that parameter to "index". Apply minor coding style fixes to the rest of the function as well. [ darwi: Move into a separate commit and write commit log. Use "index" instead of "subleaf" for amd_cpuid4() first param, as that's the name typically used at the whole of cacheinfo.c. ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-7-darwi@linutronix.de
2025-03-25x86/cacheinfo: Refactor CPUID leaf 0x2 cache descriptor lookupThomas Gleixner
Extract the cache descriptor lookup logic out of the leaf 0x2 parsing code and into a dedicated function. This disentangles such lookup from the deeply nested leaf 0x2 parsing loop. Remove the cache table termination entry, as it is no longer needed after the ARRAY_SIZE()-based lookup. [ darwi: Move refactoring logic into this separate commit + commit log. Remove the cache table termination entry. ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-6-darwi@linutronix.de
2025-03-25x86/cacheinfo: Use CPUID leaf 0x2 parsing helpersAhmed S. Darwish
Parent commit introduced CPUID leaf 0x2 parsing helpers at <asm/cpuid/leaf_0x2_api.h>. The new API allows sharing leaf 0x2's output validation and iteration logic across both intel.c and cacheinfo.c. Convert cacheinfo.c to that new API. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-5-darwi@linutronix.de
2025-03-25x86/cpu: Introduce and use CPUID leaf 0x2 parsing helpersAhmed S. Darwish
Introduce CPUID leaf 0x2 parsing helpers at <asm/cpuid/leaf_0x2_api.h>. This allows sharing the leaf 0x2's output validation and iteration logic across both x86/cpu intel.c and cacheinfo.c. Start by converting intel.c to the new API. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-4-darwi@linutronix.de
2025-03-25x86/cacheinfo: Remove CPUID leaf 0x2 parsing loopAhmed S. Darwish
Leaf 0x2 output includes a "query count" byte where it was supposed to specify the number of repeated CPUID leaf 0x2 subleaf 0 queries needed to extract all of the CPU's cache and TLB descriptors. Per current Intel manuals, all CPUs supporting this leaf "will always" return an iteration count of 1. Remove the leaf 0x2 query loop and just query the hardware once. Note, as previously done at commit aec28d852ed2 ("x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>"), standardize on using 'u32' and 'u8' types. Suggested-by: Ingo Molnar <mingo@kernel.org> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-3-darwi@linutronix.de
2025-03-25x86/cpu: Remove CPUID leaf 0x2 parsing loopAhmed S. Darwish
Leaf 0x2 output includes a "query count" byte where it was supposed to specify the number of repeated CPUID leaf 0x2 subleaf 0 queries needed to extract all of the CPU's cache and TLB descriptors. Per current Intel manuals, all CPUs supporting this leaf "will always" return an iteration count of 1. Remove the leaf 0x2 query loop and just query the hardware once. Note, as previously done in: aec28d852ed2 ("x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>") standardize on using 'u32' and 'u8' types. Suggested-by: Ingo Molnar <mingo@kernel.org> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250324133324.23458-2-darwi@linutronix.de
2025-03-25MAINTAINERS: Include the entire kcpuid/ directory under the X86 CPUID ↵Ahmed S. Darwish
DATABASE entry kcpuid's CSV file is covered by the "x86 CPUID database" MAINTAINERS entry. Recent patches have shown that changes to that file may require updates to the kcpuid code, so include the whole of tools/x86/kcpuid/ under the same entry. This also ensures that myself and the x86-cpuid mailing list are CCed on future kcpuid patches. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-21-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Update bitfields to x86-cpuid-db v2.3Ahmed S. Darwish
Update kcpuid's CSV file to version 2.3, as generated by x86-cpuid-db. Summary of the v2.3 changes: * Per H. Peter Anvin's feedback, leaf 0x3 is not unique to Transmeta as the CSV file earlier claimed. Since leaf 0x3's format differs between Intel and Transmeta, and the project does not yet support having the same CPUID bitfield with varying interpretations across vendors, leaf 0x3 is removed for now. Given that Intel discontinued support for PSN from Pentium 4 onward, and Linux force disables it on early boot for privacy concerns, this should have minimal impact. * Leaf 0x80000021: Make bitfield IDs and descriptions coherent with each other. Remove "_support" from bitfield IDs, as no other leaf has such convention. Reported-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v2.3/CHANGELOG.rst Link: https://lore.kernel.org/r/20250324142042.29010-20-darwi@linutronix.de Closes: https://lkml.kernel.org/r/C7684E03-36E0-4D58-B6F0-78F4DB82D737@zytor.com
2025-03-25tools/x86/kcpuid: Update bitfields to x86-cpuid-db v2.2Ahmed S. Darwish
Update kcpuid's CSV file to version 2.2, as generated by x86-cpuid-db. Per Ingo Molnar's feedback, it is desired to always use CPUID in its capitalized form. The v2.2 release fixed all instances of small case "cpuid" at the project's XML database, and thus all of its generated files. Reported-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v2.2/CHANGELOG.rst Link: https://lore.kernel.org/r/20250324142042.29010-19-darwi@linutronix.de Closes: https://lkml.kernel.org/r/Z8bHK391zKE4gUEW@gmail.com
2025-03-25tools/x86/kcpuid: Update bitfields to x86-cpuid-db v2.1Ahmed S. Darwish
Update kcpuid's CSV file to version 2.1, as generated by x86-cpuid-db. Summary of the v2.1 changes: * Use a standardized style for all x86 trademarks, registers, opcodes, byte units, hexadecimal digits, and x86 technical terms. This was enforced by a number of x86-specific hunspell(5) dictionary and affix files at the x86-cpuid-db project's CI pipeline. * Expand abbreviated terms that might be OK in code but not in official listings (e.g., "addr", "instr", "reg", "virt", etc.) * Add new Zen5 SoC bits to leaf 0x80000020 and leaf 0x80000021. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v2.1/CHANGELOG.rst Link: https://lore.kernel.org/r/20250324142042.29010-18-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Update bitfields to x86-cpuid-db v2.0Ahmed S. Darwish
Update kcpuid's CSV file to version v2.0, as generated by x86-cpuid-db. Summary of the v2.0 changes: * Introduce the leaves: - Leaf 0x00000003, Transmeta Processor serial number - Leaf 0x80860000, Transmeta max leaf number + CPU vendor ID - Leaf 0x80860001, Transmeta extended CPU information - Leaf 0x80860002, Transmeta Code Morphing Software (CMS) enumeration - Leaf 0x80860003 => 0x80860006, Transmeta CPU information string - Leaf 0x80860007, Transmeta "live" CPU information - Leaf 0xc0000000, Centaur/Zhaoxin's max leaf number - Leaf 0xc0000001, Centaur/Zhaoxin's extended CPU features * Add a 0x prefix for leaves 0x0 to 0x9. This maintains consistency with the rest of the CSV entries. * Add the new bitfields: - Leaf 0x7: nmi_src, NMI-source reporting - Leaf 0x80000001: e_base_type and e_mmx (Transmeta) * Update the section headers for leaves 0x80000000 and 0x80000005 to indicate that they are also valid for Transmeta. Notes: Leaf 0x3, being not unique to Transmeta, is handled at the generated CSV file v2.3 update, later in this patch queue. Leaf 0x80000001 EDX:23 bit, e_mmx, is also available on AMD. A bugfix is already merged at x86-cpuid-db's -tip for that, and it will be part of the project's upcoming v2.4 release.: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/commit/65fff25daa41 Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v2.0/CHANGELOG.rst Link: https://lore.kernel.org/r/20250324142042.29010-17-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Define Transmeta and Centaur index rangesAhmed S. Darwish
Explicitly define the CPUID index ranges for Transmeta (0x80860000) and Centaur/Zhaoxin (0xc0000000). Without these explicit definitions, their respective CPUID indices would be skipped during CSV bitfield parsing. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-16-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Filter valid CPUID rangesAhmed S. Darwish
Next commits will introduce vendor-specific CPUID ranges like Transmeta's 0x8086000 range and Centaur's 0xc0000000. Initially explicit vendor detection was implemented, but it turned out to be not strictly necessary. As Dave Hansen noted, even established tools like cpuid(1) just tries all ranges indices, and see if the CPU responds back with something sensible. Do something similar at setup_cpuid_range(). Query the range's index, and check the maximum range function value returned. If it's within an expected interval of [range_index, range_index + MAX_RANGE_INDEX_OFFSET], accept the range as valid and further query its leaves. Set MAX_RANGE_INDEX_OFFSET to a heuristic of 0xff. That should be sensible enough since all the ranges covered by x86-cpuid-db XML database are: 0x00000000 0x00000023 0x40000000 0x40000000 0x80000000 0x80000026 0x80860000 0x80860007 0xc0000000 0xc0000001 At setup_cpuid_range(), if the range's returned maximum function was not sane, mark it as invalid by setting its number of leaves, range->nr, to zero. Introduce the for_each_valid_cpuid_range() iterator instead of sprinkling "range->nr != 0" checks throughout the code. Suggested-by: Dave Hansen <dave.hansen@intel.com> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-15-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Consolidate index validity checksAhmed S. Darwish
Let index_to_cpuid_range() return a CPUID range only if the passed index is within a CPUID range's maximum supported function on the CPU. Returning a CPUID range that is invalid on the CPU for the passed index does not make sense. This also avoids repeating the "function index is within CPUID range" checks, both at setup_cpuid_range() and index_to_func(). Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-14-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Extend CPUID index mask macroAhmed S. Darwish
Extend the CPUID index mask macro from 0x80000000 to 0xffff0000. This accommodates the Transmeta (0x80860000) and Centaur (0xc0000000) index ranges which will be later added. This also automatically sets CPUID_FUNCTION_MASK to 0x0000ffff, which is the actual correct value. Use that macro, instead of the 0xffff literal where appropriate. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-13-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Refactor CPUID range handling for future expansionAhmed S. Darwish
The kcpuid code assumes only two CPUID index ranges, standard (0x0...) and extended (0x80000000...). Since additional CPUID index ranges will be added in further commits, replace the "is_ext" boolean with enumeration-based range classification. Collect all CPUID ranges in a structured array and introduce helper macros to iterate over it. Use such helpers throughout the code. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-12-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Use <cpuid.h> intrinsicsAhmed S. Darwish
Use the __cpuid_count() intrinsic, provided by GCC and LLVM, instead of rolling a manual version. Both of the kernel's minimum required GCC version (5.1) and LLVM version (13.0.1) supports it, and it is heavily used across standard Linux user-space tooling. This also makes the CPUID call sites more readable. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-11-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Use C99-style for loopsAhmed S. Darwish
Since commit e8c07082a810 ("Kbuild: move to -std=gnu11") and the kernel allows C99-style variable declarations inside of a for() loop. Adjust the kcpuid code accordingly. Note, this helps readability as some of the kcpuid functions have a huge list of variable declarations on top. Note, remove the empty lines before cpuid() invocations as it is clearer to have their parameter initialization and the actual call in one block. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-10-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Set parse_line() return type to voidAhmed S. Darwish
parse_line() returns an integer but its caller ignored it. Change the function signature to return void. While at it, adjust some of the "Skip line" comments for readability. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-9-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Remove unused global variableAhmed S. Darwish
The global variable "is_amd" is written to, but is not read from anywhere. Remove it. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-8-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Remove unused local variableAhmed S. Darwish
The local variable "index" is written to, but is not read from anywhere. Remove it. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-7-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Print correct CPUID output register namesAhmed S. Darwish
kcpuid --all --detail claims that all bits belong to ECX, in the form of the header CPUID_${leaf}_ECX[${subleaf}]. Print the correct register name for all CPUID output. kcpuid --detail also dumps the raw register value if a leaf/subleaf is covered in the CSV file, but a certain output register within it is not covered by any CSV entry. Since register names are now properly printed, and since the CSV file has become exhaustive using x86-cpuid-db, remove that value dump as it pollutes the output. While at it, rename decode_bits() to show_reg(). This makes it match its show_range(), show_leaf() and show_reg_header() counterparts. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-6-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Save CPUID output in an arrayAhmed S. Darwish
For each CPUID leaf/subleaf query, save the output in an output[] array instead of spelling it out using EAX to EDX variables. This allows the CPUID output to be accessed programmatically instead of calling decode_bits() four times. Loop-based access also allows "kcpuid --detail" to print the correct output register names in next commit. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-5-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Simplify usage() handlingAhmed S. Darwish
Refactor usage() to accept an exit code parameter and exit the program after usage output. This streamlines its callers' code paths. Remove the "Invalid option" error message since getopt_long(3) already emits a similar message by default. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-4-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Exit the program on invalid parametersAhmed S. Darwish
If the user passed an invalid CPUID index value through --leaf=index, kcpuid prints a warning, does nothing, then exits successfully. Transform the warning to an error, and exit the program with a proper error code. Similarly, if the user passed an invalid subleaf, kcpuid prints a warning, dumps the whole leaf, then exits successfully. Print a clear error message regarding the invalid subleaf and exit the program with the proper error code. Note, moving the "Invalid input index" message from index_to_func() to show_info() localizes error message handling to the latter, where it should be. It also allows index_to_func() to be refactored at further commits. Note, since after this commit and its parent kcpuid does not just "move on" on failures, remove the NULL parameter check plus silent exit at show_func() and show_leaf(). Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-3-darwi@linutronix.de
2025-03-25tools/x86/kcpuid: Fix error handlingAhmed S. Darwish
Error handling in kcpuid is unreliable. On malloc() failures, the code prints an error then just goes on. The error messages are also printed to standard output instead of standard error. Use err() and errx() from <err.h> to direct all error messages to standard error and automatically exit the program. Use err() to include the errno information, and errx() otherwise. Use warnx() for warnings. While at it, alphabetically reorder the header includes. [ mingo: Fix capitalization in the help text while at it. ] Fixes: c6b2f240bf8d ("tools/x86: Add a kcpuid tool to show raw CPU features") Reported-by: Remington Brasga <rbrasga@uci.edu> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Link: https://lore.kernel.org/r/20250324142042.29010-2-darwi@linutronix.de Closes: https://lkml.kernel.org/r/20240926223557.2048-1-rbrasga@uci.edu
2025-03-24x86 boot build: make git ignore stale 'tools' directoryLinus Torvalds
We've had this before: when we remove infrastructure to generate files, the old stale build artifacts still remain in-tree. And when the infrastructure to generate them is gone, so is the gitignore file for those build artifacts. End result: git will see the old generated files, and people will mistakenly commit them. That's what happened with the 'genheaders' file not that long ago (see commit 04a3389b3535 "Remove stale generated 'genheaders' file"). This time it's commit 9c54baab4401 ("x86/boot: Drop CRC-32 checksum and the build tool that generates it") that removed the 'build' file from the arch/x86/boot/tools/ subdirectory, and removed the .gitignore file too (because the whole subdirectory is gone). And as a result, if you don't do a 'git clean -dqfx' or similar to clean up your tree, 'git status' will say Untracked files: (use "git add <file>..." to include in what will be committed) arch/x86/boot/tools/ and some hapless sleep-deprived developer will inevitably decide that that means that they need to 'git add' that directory. Which would bring back some stale generated file that we most definitely do not want in the tree. So when removing directories that had special .gitignore patterns, make sure to add a new gitignore entry in the parent directory for the no longer existing subdirectory. It will avoid mistakes. Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Fixes: 9c54baab4401 ("x86/boot: Drop CRC-32 checksum and the build tool that generates it") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-03-24Merge tag 'x86-platform-2025-03-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 platform updates from Ingo Molnar: "Two small cleanups in the x86 platform support code" * tag 'x86-platform-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/platform/olpc: Remove unused variable 'len' in olpc_dt_compatible_match() x86/platform/olpc-xo1-sci: Don't include <linux/pm_wakeup.h> directly
2025-03-24Merge tag 'x86-sev-2025-03-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 SEV updates from Ingo Molnar: - Improve sme_enable() PIC build robustness (Kevin Loughlin) - Simplify vc_handle_msr() a bit (Peng Hao) [ Just reminding myself and everybody else about the endless stream of x86 TLAs: "SEV" is AMD's Secure Encrypted Virtualization - Linus ] * tag 'x86-sev-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sev: Simplify the code by removing unnecessary 'else' statement x86/sev: Add missing RIP_REL_REF() invocations during sme_enable()
2025-03-24Merge tag 'x86-cleanups-2025-03-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 cleanups from Ingo Molnar: "Miscellaneous x86 cleanups by Arnd Bergmann, Charles Han, Mirsad Todorovac, Randy Dunlap, Thorsten Blum and Zhang Kunbo" * tag 'x86-cleanups-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/coco: Replace 'static const cc_mask' with the newly introduced cc_get_mask() function x86/delay: Fix inconsistent whitespace selftests/x86/syscall: Fix coccinelle WARNING recommending the use of ARRAY_SIZE() x86/platform: Fix missing declaration of 'x86_apple_machine' x86/irq: Fix missing declaration of 'io_apic_irqs' x86/usercopy: Fix kernel-doc func param name in clean_cache_range()'s description x86/apic: Use str_disabled_enabled() helper in print_ipi_mode()
2025-03-24Merge tag 'x86-fpu-2025-03-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86/fpu updates from Ingo Molnar: - Improve crypto performance by making kernel-mode FPU reliably usable in softirqs ((Eric Biggers) - Fully optimize out WARN_ON_FPU() (Eric Biggers) - Initial steps to support Support Intel APX (Advanced Performance Extensions) (Chang S. Bae) - Fix KASAN for arch_dup_task_struct() (Benjamin Berg) - Refine and simplify the FPU magic number check during signal return (Chang S. Bae) - Fix inconsistencies in guest FPU xfeatures (Chao Gao, Stanislav Spassov) - selftests/x86/xstate: Introduce common code for testing extended states (Chang S. Bae) - Misc fixes and cleanups (Borislav Petkov, Colin Ian King, Uros Bizjak) * tag 'x86-fpu-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/fpu/xstate: Fix inconsistencies in guest FPU xfeatures x86/fpu: Clarify the "xa" symbolic name used in the XSTATE* macros x86/fpu: Use XSAVE{,OPT,C,S} and XRSTOR{,S} mnemonics in xstate.h x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs x86/fpu/xstate: Simplify print_xstate_features() x86/fpu: Refine and simplify the magic number check during signal return selftests/x86/xstate: Fix spelling mistake "hader" -> "header" x86/fpu: Avoid copying dynamic FP state from init_task in arch_dup_task_struct() vmlinux.lds.h: Remove entry to place init_task onto init_stack selftests/x86/avx: Add AVX tests selftests/x86/xstate: Clarify supported xstates selftests/x86/xstate: Consolidate test invocations into a single entry selftests/x86/xstate: Introduce signal ABI test selftests/x86/xstate: Refactor ptrace ABI test selftests/x86/xstate: Refactor context switching test selftests/x86/xstate: Enumerate and name xstate components selftests/x86/xstate: Refactor XSAVE helpers for general use selftests/x86: Consolidate redundant signal helper functions x86/fpu: Fix guest FPU state buffer allocation size x86/fpu: Fully optimize out WARN_ON_FPU()
2025-03-24Merge tag 'x86-boot-2025-03-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 boot code updates from Ingo Molnar: - Memblock setup and other early boot code cleanups (Mike Rapoport) - Export e820_table_kexec[] to sysfs (Dave Young) - Baby steps of adding relocate_kernel() debugging support (David Woodhouse) - Replace open-coded parity calculation with parity8() (Kuan-Wei Chiu) - Move the LA57 trampoline to separate source file (Ard Biesheuvel) - Misc micro-optimizations (Uros Bizjak) - Drop obsolete E820_TYPE_RESERVED_KERN and related code (Mike Rapoport) * tag 'x86-boot-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/kexec: Add relocate_kernel() debugging support: Load a GDT x86/boot: Move the LA57 trampoline to separate source file x86/boot: Do not test if AC and ID eflags are changeable on x86_64 x86/bootflag: Replace open-coded parity calculation with parity8() x86/bootflag: Micro-optimize sbf_write() x86/boot: Add missing has_cpuflag() prototype x86/kexec: Export e820_table_kexec[] to sysfs x86/boot: Change some static bootflag functions to bool x86/e820: Drop obsolete E820_TYPE_RESERVED_KERN and related code x86/boot: Split parsing of boot_params into the parse_boot_params() helper function x86/boot: Split kernel resources setup into the setup_kernel_resources() helper function x86/boot: Move setting of memblock parameters to e820__memblock_setup()
2025-03-24Merge tag 'x86-build-2025-03-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 build updates from Ingo Molnar: - Drop CRC-32 checksum and the build tool that generates it (Ard Biesheuvel) - Fix broken copy command in genimage.sh when making isoimage (Nir Lichtman) * tag 'x86-build-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/boot: Add back some padding for the CRC-32 checksum x86/boot: Drop CRC-32 checksum and the build tool that generates it x86/build: Fix broken copy command in genimage.sh when making isoimage
2025-03-24Merge tag 'x86-core-2025-03-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull core x86 updates from Ingo Molnar: "x86 CPU features support: - Generate the <asm/cpufeaturemasks.h> header based on build config (H. Peter Anvin, Xin Li) - x86 CPUID parsing updates and fixes (Ahmed S. Darwish) - Introduce the 'setcpuid=' boot parameter (Brendan Jackman) - Enable modifying CPU bug flags with '{clear,set}puid=' (Brendan Jackman) - Utilize CPU-type for CPU matching (Pawan Gupta) - Warn about unmet CPU feature dependencies (Sohil Mehta) - Prepare for new Intel Family numbers (Sohil Mehta) Percpu code: - Standardize & reorganize the x86 percpu layout and related cleanups (Brian Gerst) - Convert the stackprotector canary to a regular percpu variable (Brian Gerst) - Add a percpu subsection for cache hot data (Brian Gerst) - Unify __pcpu_op{1,2}_N() macros to __pcpu_op_N() (Uros Bizjak) - Construct __percpu_seg_override from __percpu_seg (Uros Bizjak) MM: - Add support for broadcast TLB invalidation using AMD's INVLPGB instruction (Rik van Riel) - Rework ROX cache to avoid writable copy (Mike Rapoport) - PAT: restore large ROX pages after fragmentation (Kirill A. Shutemov, Mike Rapoport) - Make memremap(MEMREMAP_WB) map memory as encrypted by default (Kirill A. Shutemov) - Robustify page table initialization (Kirill A. Shutemov) - Fix flush_tlb_range() when used for zapping normal PMDs (Jann Horn) - Clear _PAGE_DIRTY for kernel mappings when we clear _PAGE_RW (Matthew Wilcox) KASLR: - x86/kaslr: Reduce KASLR entropy on most x86 systems, to support PCI BAR space beyond the 10TiB region (CONFIG_PCI_P2PDMA=y) (Balbir Singh) CPU bugs: - Implement FineIBT-BHI mitigation (Peter Zijlstra) - speculation: Simplify and make CALL_NOSPEC consistent (Pawan Gupta) - speculation: Add a conditional CS prefix to CALL_NOSPEC (Pawan Gupta) - RFDS: Exclude P-only parts from the RFDS affected list (Pawan Gupta) System calls: - Break up entry/common.c (Brian Gerst) - Move sysctls into arch/x86 (Joel Granados) Intel LAM support updates: (Maciej Wieczor-Retman) - selftests/lam: Move cpu_has_la57() to use cpuinfo flag - selftests/lam: Skip test if LAM is disabled - selftests/lam: Test get_user() LAM pointer handling AMD SMN access updates: - Add SMN offsets to exclusive region access (Mario Limonciello) - Add support for debugfs access to SMN registers (Mario Limonciello) - Have HSMP use SMN through AMD_NODE (Yazen Ghannam) Power management updates: (Patryk Wlazlyn) - Allow calling mwait_play_dead with an arbitrary hint - ACPI/processor_idle: Add FFH state handling - intel_idle: Provide the default enter_dead() handler - Eliminate mwait_play_dead_cpuid_hint() Build system: - Raise the minimum GCC version to 8.1 (Brian Gerst) - Raise the minimum LLVM version to 15.0.0 (Nathan Chancellor) Kconfig: (Arnd Bergmann) - Add cmpxchg8b support back to Geode CPUs - Drop 32-bit "bigsmp" machine support - Rework CONFIG_GENERIC_CPU compiler flags - Drop configuration options for early 64-bit CPUs - Remove CONFIG_HIGHMEM64G support - Drop CONFIG_SWIOTLB for PAE - Drop support for CONFIG_HIGHPTE - Document CONFIG_X86_INTEL_MID as 64-bit-only - Remove old STA2x11 support - Only allow CONFIG_EISA for 32-bit Headers: - Replace __ASSEMBLY__ with __ASSEMBLER__ in UAPI and non-UAPI headers (Thomas Huth) Assembly code & machine code patching: - x86/alternatives: Simplify alternative_call() interface (Josh Poimboeuf) - x86/alternatives: Simplify callthunk patching (Peter Zijlstra) - KVM: VMX: Use named operands in inline asm (Josh Poimboeuf) - x86/hyperv: Use named operands in inline asm (Josh Poimboeuf) - x86/traps: Cleanup and robustify decode_bug() (Peter Zijlstra) - x86/kexec: Merge x86_32 and x86_64 code using macros from <asm/asm.h> (Uros Bizjak) - Use named operands in inline asm (Uros Bizjak) - Improve performance by using asm_inline() for atomic locking instructions (Uros Bizjak) Earlyprintk: - Harden early_serial (Peter Zijlstra) NMI handler: - Add an emergency handler in nmi_desc & use it in nmi_shootdown_cpus() (Waiman Long) Miscellaneous fixes and cleanups: - by Ahmed S. Darwish, Andy Shevchenko, Ard Biesheuvel, Artem Bityutskiy, Borislav Petkov, Brendan Jackman, Brian Gerst, Dan Carpenter, Dr. David Alan Gilbert, H. Peter Anvin, Ingo Molnar, Josh Poimboeuf, Kevin Brodsky, Mike Rapoport, Lukas Bulwahn, Maciej Wieczor-Retman, Max Grobecker, Patryk Wlazlyn, Pawan Gupta, Peter Zijlstra, Philip Redkin, Qasim Ijaz, Rik van Riel, Thomas Gleixner, Thorsten Blum, Tom Lendacky, Tony Luck, Uros Bizjak, Vitaly Kuznetsov, Xin Li, liuye" * tag 'x86-core-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (211 commits) zstd: Increase DYNAMIC_BMI2 GCC version cutoff from 4.8 to 11.0 to work around compiler segfault x86/asm: Make asm export of __ref_stack_chk_guard unconditional x86/mm: Only do broadcast flush from reclaim if pages were unmapped perf/x86/intel, x86/cpu: Replace Pentium 4 model checks with VFM ones perf/x86/intel, x86/cpu: Simplify Intel PMU initialization x86/headers: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-UAPI headers x86/headers: Replace __ASSEMBLY__ with __ASSEMBLER__ in UAPI headers x86/locking/atomic: Improve performance by using asm_inline() for atomic locking instructions x86/asm: Use asm_inline() instead of asm() in clwb() x86/asm: Use CLFLUSHOPT and CLWB mnemonics in <asm/special_insns.h> x86/hweight: Use asm_inline() instead of asm() x86/hweight: Use ASM_CALL_CONSTRAINT in inline asm() x86/hweight: Use named operands in inline asm() x86/stackprotector/64: Only export __ref_stack_chk_guard on CONFIG_SMP x86/head/64: Avoid Clang < 17 stack protector in startup code x86/kexec: Merge x86_32 and x86_64 code using macros from <asm/asm.h> x86/runtime-const: Add the RUNTIME_CONST_PTR assembly macro x86/cpu/intel: Limit the non-architectural constant_tsc model checks x86/mm/pat: Replace Intel x86_model checks with VFM ones x86/cpu/intel: Fix fast string initialization for extended Families ...