Changes in Makefile

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

Thu, 08 Aug 2024 06:29:34 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Tue, 07 May 2024 04:24:22 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Sat, 27 Apr 2024 14:55:02 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Tue, 13 Feb 2024 21:05:35 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

6cf70394 - x86/cpu: Remove topology.c

Tue, 13 Feb 2024 21:04:20 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Tue, 13 Feb 2024 21:04:11 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Tue, 13 Feb 2024 21:04:07 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Tue, 13 Feb 2024 21:04:01 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

48525fd1 - x86/cpu: Provide debug interface

Mon, 14 Aug 2023 08:18:47 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

7583e8fb - x86/cpu: Remove X86_FEATURE_NAMES

Wed, 10 May 2023 06:57:13 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

2cb15faa - x86/cpu: Re-enable stackprotector

Thu, 15 Sep 2022 11:10:43 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Thu, 15 Sep 2022 15:04:06 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Sun, 17 Oct 2021 09:44:10 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Thu, 12 Nov 2020 22:01:16 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

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

Fri, 26 Jun 2020 18:59:12 +0000

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-6.15/arch/x86/kernel/cpu/Makefile

14442a15 - x86/cpu: Print VMX flags in /proc/cpuinfo using VMX_FEATURES_*

Sat, 21 Dec 2019 04:45:05 +0000

x86/cpu: Print VMX flags in /proc/cpuinfo using VMX_FEATURES_*Add support for generating VMX feature names in capflags.c and use theresulting x86_vmx_flags to print the VMX flags in /proc/cpuinfo. Don'tprint VMX flags if no bits are set in word 0, which holds Pin Controls.Pin Control's INTR and NMI exiting are fundamental pillars of VMX, ifthey are not supported then the CPU is broken, it does not actuallysupport VMX, or the kernel wasn't built with support for the target CPU.Print the features in a dedicated "vmx flags" line to avoid pollutingthe common "flags" and to avoid having to prefix all flags with "vmx_",which results in horrendously long names.Keep synthetic VMX flags in cpufeatures to preserve /proc/cpuinfo's ABIfor those flags. This means that "flags" and "vmx flags" will haveduplicate entries for tpr_shadow (virtual_tpr), vnmi, ept, flexpriority,vpid and ept_ad, but caps the pollution of "flags" at those six VMXfeatures. The vendor-specific code that populates the synthetic flagswill be consolidated in a future patch to further minimize the lastingdamage.Signed-off-by: Sean Christopherson Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20191221044513.21680-12-sean.j.christopherson@intel.com List of files: /linux-6.15/arch/x86/kernel/cpu/Makefile

1db2a6e1 - x86/intel: Initialize IA32_FEAT_CTL MSR at boot

Sat, 21 Dec 2019 04:44:58 +0000

x86/intel: Initialize IA32_FEAT_CTL MSR at bootOpportunistically initialize IA32_FEAT_CTL to enable VMX when the MSR isleft unlocked by BIOS. Configuring feature control at boot time pavesthe way for similar enabling of other features, e.g. Software GuardExtensions (SGX).Temporarily leave equivalent KVM code in place in order to avoidintroducing a regression on Centaur and Zhaoxin CPUs, e.g. removingKVM's code would leave the MSR unlocked on those CPUs and would breakexisting functionality if people are loading kvm_intel on Centaur and/orZhaoxin. Defer enablement of the boot-time configuration on Centaur andZhaoxin to future patches to aid bisection.Note, Local Machine Check Exceptions (LMCE) are also supported by thekernel and enabled via feature control, but the kernel currently usesLMCE if and only if the feature is explicitly enabled by BIOS. Keepthe current behavior to avoid introducing bugs, future patches can optin to opportunistic enabling if it's deemed desirable to do so.Always lock IA32_FEAT_CTL if it exists, even if the CPU doesn't supportVMX, so that other existing and future kernel code that queries the MSRcan assume it's locked.Start from a clean slate when constructing the value to write toIA32_FEAT_CTL, i.e. ignore whatever value BIOS left in the MSR so as notto enable random features or fault on the WRMSR.Suggested-by: Borislav Petkov Signed-off-by: Sean Christopherson Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20191221044513.21680-5-sean.j.christopherson@intel.com List of files: /linux-6.15/arch/x86/kernel/cpu/Makefile

40d04110 - x86, kcsan: Enable KCSAN for x86

Thu, 14 Nov 2019 18:03:03 +0000

x86, kcsan: Enable KCSAN for x86This patch enables KCSAN for x86, with updates to build rules to not useKCSAN for several incompatible compilation units.Signed-off-by: Marco Elver Acked-by: Paul E. McKenney Signed-off-by: Paul E. McKenney List of files: /linux-6.15/arch/x86/kernel/cpu/Makefile

95c5824f - x86/cpu: Add a "tsx=" cmdline option with TSX disabled by default

Wed, 23 Oct 2019 09:01:53 +0000

x86/cpu: Add a "tsx=" cmdline option with TSX disabled by defaultAdd a kernel cmdline parameter "tsx" to control the TransactionalSynchronization Extensions (TSX) feature. On CPUs that support TSXcontrol, use "tsx=on|off" to enable or disable TSX. Not specifying thisoption is equivalent to "tsx=off". This is because on certain processorsTSX may be used as a part of a speculative side channel attack.Carve out the TSX controlling functionality into a separate compilationunit because TSX is a CPU feature while the TSX async abort controlmachinery will go to cpu/bugs.c. [ bp: - Massage, shorten and clear the arg buffer. - Clarifications of the tsx= possible options - Josh. - Expand on TSX_CTRL availability - Pawan. ]Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Reviewed-by: Josh Poimboeuf List of files: /linux-6.15/arch/x86/kernel/cpu/Makefile

87b61864 - x86/build: Remove redundant 'clean-files += capflags.c'

Tue, 25 Jun 2019 07:33:11 +0000

x86/build: Remove redundant 'clean-files += capflags.c'All the files added to 'targets' are cleaned. Adding the same file to both'targets' and 'clean-files' is redundant.Signed-off-by: Masahiro Yamada Signed-off-by: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Borislav Petkov Link: https://lkml.kernel.org/r/20190625073311.18303-1-yamada.masahiro@socionext.com List of files: /linux-6.15/arch/x86/kernel/cpu/Makefile