Changes in Makefile

fa6dcbc69ad495eeea315870278100a554a4ca18 - x86/cpuid: Introduce a centralized CPUID parser

Fri, 27 Mar 2026 03:15:23 +0100

x86/cpuid: Introduce a centralized CPUID parserIntroduce a CPUID parser for populating the system's CPUID tables.Since accessing a leaf within the CPUID table requires compile timetokenization, split the parser into two stages: (a) Compile-time macros for tokenizing the leaf/subleaf offsets within the CPUID table. (b) Generic runtime code to fill the CPUID data, using a parsing table which collects these compile-time offsets.For actual CPUID output parsing, support both generic and leaf-specificread functions.To ensure CPUID data early availability, invoke the parser during earlyboot, early Xen boot, and at early secondary CPUs bring up.Provide call site APIs to refresh a single leaf, or a leaf range, withinthe CPUID tables. This is for sites issuing MSR writes that partiallychange the CPU's CPUID layout. Doing full CPUID table rescans in suchcases will be destructive since the CPUID tables will host all of thekernel's X86_FEATURE flags at a later stage.Suggested-by: Thomas Gleixner Signed-off-by: Ahmed S. Darwish Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/all/20260327021645.555257-1-darwi@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

fa1d117162aa820a8f73a31ccab85bde6c84725b - x86/cpu: Detect FreeBSD Bhyve hypervisor

Sat, 16 Aug 2025 12:06:32 +0200

x86/cpu: Detect FreeBSD Bhyve hypervisorDetect the Bhyve hypervisor and enable 15-bit MSI support if available.Detecting Bhyve used to be a purely cosmetic issue of the kernel printing'Hypervisor detected: Bhyve' at boot time.But FreeBSD 15.0 will support¹ the 15-bit MSI enlightenment to supportmore than 255 vCPUs (http://david.woodhou.se/ExtDestId.pdf) which meansthere's now actually some functional reason to do so. ¹ https://github.com/freebsd/freebsd-src/commit/313a68ea20b4 [ bp: Massage, move tail comment ontop. ]Signed-off-by: David Woodhouse Signed-off-by: Borislav Petkov (AMD) Acked-by: Ahmed S. Darwish Link: https://lore.kernel.org/03802f6f7f5b5cf8c5e8adfe123c397ca8e21093.camel@infradead.org List of files: /linux/arch/x86/kernel/cpu/Makefile

37aedb806bc68ff23bd0d90dce1564bfb0dca911 - x86/cpu: Consolidate CPUID leaf 0x2 tables

Mon, 24 Mar 2025 14:33:15 +0100

x86/cpu: Consolidate CPUID leaf 0x2 tablesCPUID leaf 0x2 describes TLBs and caches. So there are two tables with therespective descriptor constants in intel.c and cacheinfo.c. The tablesoccupy almost 600 byte and require a loop based lookup for each variant.Combining them into one table occupies exactly 1k rodata and allows to getrid of the loop based lookup by just using the descriptor byte provided byCPUID leaf 0x2 as index into the table, which simplifies the code andreduces 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 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 Signed-off-by: Thomas Gleixner Signed-off-by: Ahmed S. Darwish Signed-off-by: Ingo Molnar Cc: H. Peter Anvin Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250324133324.23458-21-darwi@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

365e960d296ef9f36b20971aa4854ce07817a9bb - x86/cacheinfo: Move AMD cache_disable_0/1 handling to separate file

Mon, 24 Mar 2025 14:33:08 +0100

x86/cacheinfo: Move AMD cache_disable_0/1 handling to separate fileParent commit decoupled amd_northbridge out of _cpuid4_info_regs, whereit was merely "parked" there until ci_info_init() can store it in theprivate pointer of the API.Given that decoupling, move the AMD-specific L3 cache_disable_0/1 sysfscode from the generic (and already extremely convoluted) x86/cacheinfocode into its own file.Compile the file only if CONFIG_AMD_NB and CONFIG_SYSFS are bothenabled, which mirrors the existing logic.Signed-off-by: Ahmed S. Darwish Signed-off-by: Ingo Molnar Cc: H. Peter Anvin Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250324133324.23458-14-darwi@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

350afa8a1101f62ce31bc4ed6f69cf4b90ec4fa2 - x86/split_lock: Move Split and Bus lock code to a dedicated file

Thu, 08 Aug 2024 08:29:34 +0200

x86/split_lock: Move Split and Bus lock code to a dedicated fileBus Lock Detect functionality on AMD platforms works identical to Intel.Move split_lock and bus_lock specific code from intel.c to a dedicatedfile so that it can be compiled and supported on non-Intel platforms.Also, introduce CONFIG_X86_BUS_LOCK_DETECT, make it dependent onCONFIG_CPU_SUP_INTEL and add compilation dependency of the new bus_lock.cfile on CONFIG_X86_BUS_LOCK_DETECT.Signed-off-by: Ravi Bangoria Signed-off-by: Thomas Gleixner Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/all/20240808062937.1149-2-ravi.bangoria@amd.com List of files: /linux/arch/x86/kernel/cpu/Makefile

079544ec60fcba3f32e4b513442cc131211c8e22 - x86/pconfig: Remove unused MKTME pconfig code

Tue, 07 May 2024 06:24:22 +0200

x86/pconfig: Remove unused MKTME pconfig codeCode supporting Intel PCONFIG targets was an early piece of enablingfor MKTME (Multi-Key Total Memory Encryption).Since MKTME feature enablement did not follow into the kernel, removethe unused PCONFIG code.Signed-off-by: Alison Schofield Signed-off-by: Dave Hansen Acked-by: Kirill A. Shutemov Acked-by: Kai Huang Link: https://lore.kernel.org/all/4ddff30d466785b4adb1400f0518783012835141.1715054189.git.alison.schofield%40intel.com List of files: /linux/arch/x86/kernel/cpu/Makefile

b1992c3772e69a6fd0e3fc81cd4d2820c8b6eca0 - kbuild: use $(src) instead of $(srctree)/$(src) for source directory

Sat, 27 Apr 2024 16:55:02 +0200

kbuild: use $(src) instead of $(srctree)/$(src) for source directoryKbuild conventionally uses $(obj)/ for generated files, and $(src)/ forchecked-in source files. It is merely a convention without any functionaldifference. In fact, $(obj) and $(src) are exactly the same, as definedin scripts/Makefile.build: src := $(obj)When the kernel is built in a separate output directory, $(src) doesnot accurately reflect the source directory location. While Kbuildresolves this discrepancy by specifying VPATH=$(srctree) to search forsource files, it does not cover all cases. For example, when adding aheader search path for local headers, -I$(srctree)/$(src) is typicallypassed to the compiler.This introduces inconsistency between upstream and downstream Makefilesbecause $(src) is used instead of $(srctree)/$(src) for the latter.To address this inconsistency, this commit changes the semantics of$(src) so that it always points to the directory in the source tree.Going forward, the variables used in Makefiles will have the followingmeanings: $(obj) - directory in the object tree $(src) - directory in the source tree (changed by this commit) $(objtree) - the top of the kernel object tree $(srctree) - the top of the kernel source treeConsequently, $(srctree)/$(src) in upstream Makefiles need to be replacedwith $(src).Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier List of files: /linux/arch/x86/kernel/cpu/Makefile

c0a66c2847908e41c771ca2355fba935a82a9f62 - x86/cpu/topology: Move registration out of APIC code

Tue, 13 Feb 2024 22:05:35 +0100

x86/cpu/topology: Move registration out of APIC codeThe APIC/CPU registration sits in the middle of the APIC code. In fact thisis a topology evaluation function and has nothing to do with the innerworkings of the local APIC.Move it out into a file which reflects what this is about.Signed-off-by: Thomas Gleixner Tested-by: Michael Kelley Tested-by: Sohil Mehta Link: https://lore.kernel.org/r/20240213210251.543948812@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

6cf70394e7205a0d65780473aa2081839eb93471 - x86/cpu: Remove topology.c

Tue, 13 Feb 2024 22:04:20 +0100

x86/cpu: Remove topology.cNo more users. Stick it into the ugly code museum.Signed-off-by: Thomas Gleixner Tested-by: Juergen Gross Tested-by: Sohil Mehta Tested-by: Michael Kelley Tested-by: Zhang Rui Tested-by: Wang Wendy Tested-by: K Prateek Nayak Link: https://lore.kernel.org/r/20240212153625.395230346@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

f7fb3b2dd92c633871b7037773b89531c488a371 - x86/cpu: Provide an AMD/HYGON specific topology parser

Tue, 13 Feb 2024 22:04:11 +0100

x86/cpu: Provide an AMD/HYGON specific topology parserAMD/HYGON uses various methods for topology evaluation: - Leaf 0x80000008 and 0x8000001e based with an optional leaf 0xb, which is the preferred variant for modern CPUs. Leaf 0xb will be superseded by leaf 0x80000026 soon, which is just another variant of the Intel 0x1f leaf for whatever reasons. - Subleaf 0x80000008 and NODEID_MSR base - Legacy fallbackThat code is following the principle of random bits and pieces all over theplace which results in multiple evaluations and impenetrable code flows inthe same way as the Intel parsing did.Provide a sane implementation by clearly separating the three variants andbringing them in the proper preference order in one place.This provides the parsing for both AMD and HYGON because there is no pointin having a separate HYGON parser which only differs by 3 lines ofcode. Any further divergence between AMD and HYGON can be handled indifferent functions, while still sharing the existing parsers.Signed-off-by: Thomas Gleixner Tested-by: Juergen Gross Tested-by: Sohil Mehta Tested-by: Michael Kelley Tested-by: Zhang Rui Tested-by: Wang Wendy Tested-by: K Prateek Nayak Link: https://lore.kernel.org/r/20240212153625.020038641@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

3d41009425225ca5e09016c634ecee513b4713bb - x86/cpu: Provide a sane leaf 0xb/0x1f parser

Tue, 13 Feb 2024 22:04:07 +0100

x86/cpu: Provide a sane leaf 0xb/0x1f parserdetect_extended_topology() along with it's early() variant is a classicexample for duct tape engineering: - It evaluates an array of subleafs with a boatload of local variables for the relevant topology levels instead of using an array to save the enumerated information and propagate it to the right level - It has no boundary checks for subleafs - It prevents updating the die_id with a crude workaround instead of checking for leaf 0xb which does not provide die information. - It's broken vs. the number of dies evaluation as it uses: num_processors[DIE_LEVEL] / num_processors[CORE_LEVEL] which "works" only correctly if there is none of the intermediate topology levels (MODULE/TILE) enumerated.There is zero value in trying to "fix" that code as the only proper fix isto rewrite it from scratch.Implement a sane parser with proper code documentation, which will be usedfor the consolidated topology evaluation in the next step.Signed-off-by: Thomas Gleixner Tested-by: Juergen Gross Tested-by: Sohil Mehta Tested-by: Michael Kelley Tested-by: Zhang Rui Tested-by: Wang Wendy Tested-by: K Prateek Nayak Link: https://lore.kernel.org/r/20240212153624.830571770@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

ebdb20361059b3c4fd7b23cfa10c28e798b7a3d2 - x86/cpu: Provide cpu_init/parse_topology()

Tue, 13 Feb 2024 22:04:01 +0100

x86/cpu: Provide cpu_init/parse_topology()Topology evaluation is a complete disaster and impenetrable mess. It'sscattered all over the place with some vendor implementations doing earlyevaluation and some not. The most horrific part is the permanentoverwriting of smt_max_siblings and __max_die_per_package, instead ofestablishing them once on the boot CPU and validating the result on theAPs.The goals are: - One topology evaluation entry point - Proper sharing of pointlessly duplicated code - Proper structuring of the evaluation logic and preferences. - Evaluating important system wide information only once on the boot CPU - Making the 0xb/0x1f leaf parsing less convoluted and actually fixing the short comings of leaf 0x1f evaluation.Start to consolidate the topology evaluation code by providing the entrypoints for the early boot CPU evaluation and for the final parsing on theboot CPU and the APs.Move the trivial pieces into that new code: - The initialization of cpuinfo_x86::topo - The evaluation of CPUID leaf 1, which presets topo::initial_apicid - topo_apicid is set to topo::initial_apicid when invoked from early boot. When invoked for the final evaluation on the boot CPU it reads the actual APIC ID, which makes apic_get_initial_apicid() obsolete once everything is converted over.Provide a temporary helper function topo_converted() which shields off thenot yet converted CPU vendors from invoking code which would break them.This shielding covers all vendor CPUs which support SMP, but not thehistorical pure UP ones as they only need the topology info init andeventually the initial APIC initialization.Provide two new members in cpuinfo_x86::topo to store the maximum number ofSMT siblings and the number of dies per package and add them to the debugfsreadout. These two members will be used to populate this information on theboot CPU and to validate the APs against it.Signed-off-by: Thomas Gleixner Tested-by: Juergen Gross Tested-by: Sohil Mehta Tested-by: Michael Kelley Tested-by: Peter Zijlstra (Intel) Tested-by: Zhang Rui Tested-by: Wang Wendy Tested-by: K Prateek Nayak Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20240212153624.581436579@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

48525fd1ea1cfa059a580e77b10ea8790914efa2 - x86/cpu: Provide debug interface

Mon, 14 Aug 2023 10:18:47 +0200

x86/cpu: Provide debug interfaceProvide debug files which dump the topology related information ofcpuinfo_x86. This is useful to validate the upcoming conversion of thetopology evaluation for correctness or bug compatibility.Signed-off-by: Thomas Gleixner Tested-by: Juergen Gross Tested-by: Sohil Mehta Tested-by: Michael Kelley Tested-by: Peter Zijlstra (Intel) Tested-by: Zhang Rui Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20230814085113.353191313@linutronix.de List of files: /linux/arch/x86/kernel/cpu/Makefile

7583e8fbdc49a4dbd916d14863cf1deeddb982f9 - x86/cpu: Remove X86_FEATURE_NAMES

Wed, 10 May 2023 08:57:13 +0200

x86/cpu: Remove X86_FEATURE_NAMESWhile discussing to change the visibility of X86_FEATURE_NAMES (see Link)in order to remove CONFIG_EMBEDDED, Boris suggested to simply make theX86_FEATURE_NAMES functionality unconditional.As the need for really tiny kernel images has gone away and kernel imageswith !X86_FEATURE_NAMES are hardly tested, remove this config and the wholeifdeffery in the source code.Suggested-by: Borislav Petkov Signed-off-by: Lukas Bulwahn Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/all/20230509084007.24373-1-lukas.bulwahn@gmail.com/Link: https://lore.kernel.org/r/20230510065713.10996-3-lukas.bulwahn@gmail.com List of files: /linux/arch/x86/kernel/cpu/Makefile

2cb15faaedeb67f52f2ddc32b5ca152acfc422c2 - x86/cpu: Re-enable stackprotector

Thu, 15 Sep 2022 13:10:43 +0200

x86/cpu: Re-enable stackprotectorCommit 5416c2663517 ("x86: make sure load_percpu_segment has nostackprotector") disabled the stackprotector for cpu/common.c because ofload_percpu_segment(). Back then the boot stack canary was initialized veryearly in start_kernel(). Switching the per CPU area by loading the GDTcaused the stackprotector to fail with paravirt enabled kernels as theGSBASE was not updated yet. In hindsight a wrong change because it wouldhave been sufficient to ensure that the canary is the same in both per CPUareas.Commit d55535232c3d ("random: move rand_initialize() earlier") moved thestack canary initialization to a later point in the init sequence. As aconsequence the per CPU stack canary is 0 when switching the per CPU areas,so there is no requirement anymore to exclude this file.Add a comment to load_percpu_segment().Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220915111143.303010511@infradead.org List of files: /linux/arch/x86/kernel/cpu/Makefile

93324e6842148cfdb44d1437fb586b957ace1f8c - x86: kmsan: disable instrumentation of unsupported code

Thu, 15 Sep 2022 17:04:06 +0200

x86: kmsan: disable instrumentation of unsupported codeInstrumenting some files with KMSAN will result in kernel being unable tolink, boot or crashing at runtime for various reasons (e.g. infiniterecursion caused by instrumentation hooks calling instrumented codeagain).Completely omit KMSAN instrumentation in the following places: - arch/x86/boot and arch/x86/realmode/rm, as KMSAN doesn't work for i386; - arch/x86/entry/vdso, which isn't linked with KMSAN runtime; - three files in arch/x86/kernel - boot problems; - arch/x86/mm/cpu_entry_area.c - recursion.Link: https://lkml.kernel.org/r/20220915150417.722975-33-glider@google.comSigned-off-by: Alexander Potapenko Cc: Alexander Viro Cc: Alexei Starovoitov Cc: Andrey Konovalov Cc: Andrey Konovalov Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Christoph Hellwig Cc: Christoph Lameter Cc: David Rientjes Cc: Dmitry Vyukov Cc: Eric Biggers Cc: Eric Biggers Cc: Eric Dumazet Cc: Greg Kroah-Hartman Cc: Herbert Xu Cc: Ilya Leoshkevich Cc: Ingo Molnar Cc: Jens Axboe Cc: Joonsoo Kim Cc: Kees Cook Cc: Marco Elver Cc: Mark Rutland Cc: Matthew Wilcox Cc: Michael S. Tsirkin Cc: Pekka Enberg Cc: Peter Zijlstra Cc: Petr Mladek Cc: Stephen Rothwell Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vegard Nossum Cc: Vlastimil Babka Signed-off-by: Andrew Morton List of files: /linux/arch/x86/kernel/cpu/Makefile

639475d434b88b58827e1aae601ed1853803f5be - x86/CPU: Add support for Vortex CPUs

Sun, 17 Oct 2021 11:44:10 +0200

x86/CPU: Add support for Vortex CPUsDM&P devices were not being properly identified, which resulted inunneeded Spectre/Meltdown mitigations being applied.The manufacturer states that these devices execute always in-order anddon't support either speculative execution or branch prediction, sothey are not vulnerable to this class of attack. [1]This is something I've personally tested by a simple timing analysison my Vortex86MX CPU, and can confirm it is true.Add identification for some devices that lack the CPUID product namecall, so they appear properly on /proc/cpuinfo.¹https://www.ssv-embedded.de/doks/infos/DMP_Ann_180108_Meltdown.pdf [ bp: Massage commit message. ]Signed-off-by: Marcos Del Sol Vives Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20211017094408.1512158-1-marcos@orca.pet List of files: /linux/arch/x86/kernel/cpu/Makefile

e7e0545299d8cb0fd6fe3ba50401b7f5c3937362 - x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections

Thu, 12 Nov 2020 23:01:16 +0100

x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sectionsAlthough carved out of normal DRAM, enclave memory is marked in thesystem memory map as reserved and is not managed by the core mm. Theremay be several regions spread across the system. Each contiguous regionis called an Enclave Page Cache (EPC) section. EPC sections areenumerated via CPUIDEnclave pages can only be accessed when they are mapped as part of anenclave, by a hardware thread running inside the enclave.Parse CPUID data, create metadata for EPC pages and populate a simpleEPC page allocator. Although much smaller, ‘struct sgx_epc_page’metadata is the SGX analog of the core mm ‘struct page’.Similar to how the core mm’s page->flags encode zone and NUMAinformation, embed the EPC section index to the first eight bits ofsgx_epc_page->desc. This allows a quick reverse lookup from EPC page toEPC section. Existing client hardware supports only a single section,while upcoming server hardware will support at most eight sections.Thus, eight bits should be enough for long term needs.Signed-off-by: Sean Christopherson Co-developed-by: Serge Ayoun Signed-off-by: Serge Ayoun Co-developed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Borislav Petkov Acked-by: Jethro Beekman Link: https://lkml.kernel.org/r/20201112220135.165028-6-jarkko@kernel.org List of files: /linux/arch/x86/kernel/cpu/Makefile

893ab00439a45513cae55781fc8e3b7108ee1cda - kbuild: remove cc-option test of -fno-stack-protector

Fri, 26 Jun 2020 20:59:12 +0200

kbuild: remove cc-option test of -fno-stack-protectorSome Makefiles already pass -fno-stack-protector unconditionally.For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.No problem report so far about hard-coding this option. So, we canassume all supported compilers know -fno-stack-protector.GCC 4.8 and Clang support this option (https://godbolt.org/z/_HDGzN)Get rid of cc-option from -fno-stack-protector.Remove CONFIG_CC_HAS_STACKPROTECTOR_NONE, which is always 'y'.Note:arch/mips/vdso/Makefile adds -fno-stack-protector twice, firstunconditionally, and second conditionally. I removed the second one.Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Acked-by: Ard Biesheuvel Reviewed-by: Nick Desaulniers List of files: /linux/arch/x86/kernel/cpu/Makefile

a4654e9bde4ecedb4921e6c8fe2088114bdff1b3 - Merge branch 'x86/kdump' into locking/kcsan, to resolve conflicts

Sat, 21 Mar 2020 09:23:40 +0100

Merge branch 'x86/kdump' into locking/kcsan, to resolve conflictsConflicts: arch/x86/purgatory/MakefileSigned-off-by: Ingo Molnar List of files: /linux/arch/x86/kernel/cpu/Makefile