License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 15:07:57 +01:00
|
|
|
|
2008-10-22 22:26:29 -07:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:03 +01:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-11 23:03:21 +01:00
|
|
|
|
2015-07-29 01:41:16 -04:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2008-01-30 13:31:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-05 09:32:43 +02:00
|
|
|
|
2008-01-30 13:31:57 +01:00
|
|
|
|
2016-01-26 22:12:04 +01:00
|
|
|
|
x86/cpu: Introduce a centralized CPUID data model
** Context
The x86-cpuid-db project generates a C header file with full C99 bitfield
listings for all known CPUID leaf/subleaf query outputs.
That header is now merged by parent commits at <asm/cpuid/leaf_types.h>,
and is of the form:
struct leaf_0x0_0 { /* CPUID(0x0).0 C99 bitfields */ };
...
struct leaf_0x4_n { /* CPUID(0x4).n C99 bitfields */ };
...
struct leaf_0xd_0 { /* CPUID(0xd).0 C99 bitfields */ };
struct leaf_0xd_1 { /* CPUID(0xd).1 C99 bitfields */ };
struct leaf_0xd_n { /* CPUID(0xd).n C99 bitfields */ };
...
** Goal
Introduce a structured, size-efficient, per-CPU, CPUID data repository.
Use the x86-cpuid-db auto-generated data types, and custom CPUID leaf
parsers, to build that repository. Given a leaf, subleaf, and index,
provide direct memory access to the parsed and cached per-CPU CPUID output.
** Long-term goal
Remove the need for drivers and other areas in the kernel to invoke direct
CPUID queries. Only one place in the kernel should be allowed to use the
CPUID instruction: the CPUID parser code.
** Implementation
Introduce CPUID_LEAF()/CPUID_LEAF_N() to build a compact CPUID storage
layout in the form:
struct leaf_0x0_0 leaf_0x0_0[1];
struct leaf_parse_info leaf_0x0_0_info;
struct leaf_0x1_0 leaf_0x1_0[1];
struct leaf_parse_info leaf_0x0_0_info;
struct leaf_0x4_n leaf_0x4_n[8];
struct leaf_parse_info leaf_0x4_n_info;
...
where each CPUID query stores its output at the designated leaf/subleaf
array and has an associated "CPUID query info" structure.
Embed the CPUID tables inside "struct cpuinfo_x86" to ensure early-boot and
per-CPU access through the CPUs capability structures.
Use an array of CPUID output storage entries for each leaf/subleaf
combination to accommodate leaves which produce the same output format for
a large subleaf range. This is typical for CPUID leaves enumerating
hierarchical objects; e.g. CPUID(0x4) cache topology enumeration,
CPUID(0xd) XSAVE enumeration, and CPUID(0x12) SGX Enclave Page Cache
enumeration.
** New CPUID APIs
Assuming a CPU capability structure 'c', provide macros to access the
parsed and cached CPUID leaf/subleaf output. These macros resolve to a
compile-time tokenization that ensures type-safety:
const struct leaf_0x7_0 *l7_0;
l7_0 = cpuid_subleaf(c, 0x7, 0);
| | └────────┐
| └─────────┐ |
* * *
&c.cpuid.leaf_0x7_0[0]
For CPUID leaves with multiple subleaves having the same output format,
provide the APIs:
const struct leaf_0x4_n *l4_0, *l4_1;
l4_0 = cpuid_subleaf_n(c, 0x4, 0);
| | └──────────┐
| └─────────┐ |
* * v
&c.cpuid.leaf_0x4_n[0]
l4_1 = cpuid_subleaf_n(c, 0x4, 1);
| | └──────────┐
| └─────────┐ |
* * v
&c.cpuid.leaf_0x4_n[1]
where the indices 0, 1, n above can be passed dynamically; e.g., in an
enumeration for loop.
Add a clear rationale on why call sites should use the these new APIs
instead of directly invoking CPUID.
** Next steps
For now, define cached parse entries for CPUID(0x0) and CPUID(0x1).
Generic parser logic to fill the CPUID tables, along with more CPUID leaves
support, will be added next.
Suggested-by: Thomas Gleixner <tglx@kernel.org> # CPUID data model
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> # x86-cpuid-db schema
Suggested-by: Borislav Petkov <bp@alien8.de> # Early CPUID centralization drafts
Suggested-by: Ingo Molnar <mingo@kernel.org> # CPUID headers restructuring
Suggested-by: Sean Christopherson <seanjc@google.com> # cpuid_subleaf_n() APIs
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/all/20260327021645.555257-1-darwi@linutronix.de
Link: https://lore.kernel.org/all/874ixernra.ffs@tglx
Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db
Link: https://lore.kernel.org/all/aBnSgu_JyEi8fvog@gmail.com
Link: https://lore.kernel.org/all/aJ9TbaNMgaplKSbH@google.com
2026-03-27 03:15:22 +01:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2009-02-11 10:20:05 -08:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-01-30 13:31:57 +01:00
|
|
|
|
2008-01-30 13:32:38 +01:00
|
|
|
|
2012-03-28 18:11:12 +01:00
|
|
|
|
2015-04-22 09:57:24 +02:00
|
|
|
|
2017-07-11 10:33:45 -05:00
|
|
|
|
x86/vmx: Introduce VMX_FEATURES_*
Add a VMX-specific variant of X86_FEATURE_* flags, which will eventually
supplant the synthetic VMX flags defined in cpufeatures word 8. Use the
Intel-defined layouts for the major VMX execution controls so that their
word entries can be directly populated from their respective MSRs, and
so that the VMX_FEATURE_* flags can be used to define the existing bit
definitions in asm/vmx.h, i.e. force developers to define a VMX_FEATURE
flag when adding support for a new hardware feature.
The majority of Intel's (and compatible CPU's) VMX capabilities are
enumerated via MSRs and not CPUID, i.e. querying /proc/cpuinfo doesn't
naturally provide any insight into the virtualization capabilities of
VMX enabled CPUs. Commit
e38e05a85828d ("x86: extended "flags" to show virtualization HW feature
in /proc/cpuinfo")
attempted to address the issue by synthesizing select VMX features into
a Linux-defined word in cpufeatures.
Lack of reporting of VMX capabilities via /proc/cpuinfo is problematic
because there is no sane way for a user to query the capabilities of
their platform, e.g. when trying to find a platform to test a feature or
debug an issue that has a hardware dependency. Lack of reporting is
especially problematic when the user isn't familiar with VMX, e.g. the
format of the MSRs is non-standard, existence of some MSRs is reported
by bits in other MSRs, several "features" from KVM's point of view are
enumerated as 3+ distinct features by hardware, etc...
The synthetic cpufeatures approach has several flaws:
- The set of synthesized VMX flags has become extremely stale with
respect to the full set of VMX features, e.g. only one new flag
(EPT A/D) has been added in the the decade since the introduction of
the synthetic VMX features. Failure to keep the VMX flags up to
date is likely due to the lack of a mechanism that forces developers
to consider whether or not a new feature is worth reporting.
- The synthetic flags may incorrectly be misinterpreted as affecting
kernel behavior, i.e. KVM, the kernel's sole consumer of VMX,
completely ignores the synthetic flags.
- New CPU vendors that support VMX have duplicated the hideous code
that propagates VMX features from MSRs to cpufeatures. Bringing the
synthetic VMX flags up to date would exacerbate the copy+paste
trainwreck.
Define separate VMX_FEATURE flags to set the stage for enumerating VMX
capabilities outside of the cpu_has() framework, and for adding
functional usage of VMX_FEATURE_* to help ensure the features reported
via /proc/cpuinfo is up to date with respect to kernel recognition of
VMX capabilities.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20191221044513.21680-10-sean.j.christopherson@intel.com
2019-12-20 20:45:03 -08:00
|
|
|
|
2020-03-20 14:53:48 +00:00
|
|
|
|
2023-06-12 17:10:52 -07:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:57 +01:00
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
2008-01-30 13:31:57 +01:00
|
|
|
|
2009-09-02 11:49:52 +02:00
|
|
|
|
2010-03-25 14:51:50 +01:00
|
|
|
|
2012-03-28 18:11:12 +01:00
|
|
|
|
2017-07-17 16:10:07 -05:00
|
|
|
|
2012-03-28 18:11:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2009-06-01 23:43:10 +05:30
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2015-05-24 09:58:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2015-05-24 09:58:12 +02:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
|
|
|
|
|
2025-03-04 09:51:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-28 09:02:19 +08:00
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
2023-08-14 10:18:29 +02:00
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:34 +02:00
|
|
|
|
2023-08-14 10:18:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:34 +02:00
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-15 06:07:58 +00:00
|
|
|
|
2023-08-14 10:18:38 +02:00
|
|
|
|
2024-02-13 22:04:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x86/cpu: Add CPU type to struct cpuinfo_topology
Sometimes it is required to take actions based on if a CPU is a performance or
efficiency core. As an example, intel_pstate driver uses the Intel core-type
to determine CPU scaling. Also, some CPU vulnerabilities only affect
a specific CPU type, like RFDS only affects Intel Atom. Hybrid systems that
have variants P+E, P-only(Core) and E-only(Atom), it is not straightforward to
identify which variant is affected by a type specific vulnerability.
Such processors do have CPUID field that can uniquely identify them. Like,
P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE identification, while P+E
additionally enumerates CPUID.7.HYBRID. Based on this information, it is
possible for boot CPU to identify if a system has mixed CPU types.
Add a new field hw_cpu_type to struct cpuinfo_topology that stores the
hardware specific CPU type. This saves the overhead of IPIs to get the CPU
type of a different CPU. CPU type is populated early in the boot process,
before vulnerabilities are enumerated.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/r/20241025171459.1093-5-mario.limonciello@amd.com
2024-10-25 12:14:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:29 +02:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
2024-04-16 14:19:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-01 09:52:10 +08:00
|
|
|
|
2026-03-04 10:10:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-12 22:12:08 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2009-01-23 17:18:52 -08:00
|
|
|
|
2019-12-20 20:45:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-12 12:37:34 +00:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-16 15:39:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:29 +02:00
|
|
|
|
x86/cpu: Introduce a centralized CPUID data model
** Context
The x86-cpuid-db project generates a C header file with full C99 bitfield
listings for all known CPUID leaf/subleaf query outputs.
That header is now merged by parent commits at <asm/cpuid/leaf_types.h>,
and is of the form:
struct leaf_0x0_0 { /* CPUID(0x0).0 C99 bitfields */ };
...
struct leaf_0x4_n { /* CPUID(0x4).n C99 bitfields */ };
...
struct leaf_0xd_0 { /* CPUID(0xd).0 C99 bitfields */ };
struct leaf_0xd_1 { /* CPUID(0xd).1 C99 bitfields */ };
struct leaf_0xd_n { /* CPUID(0xd).n C99 bitfields */ };
...
** Goal
Introduce a structured, size-efficient, per-CPU, CPUID data repository.
Use the x86-cpuid-db auto-generated data types, and custom CPUID leaf
parsers, to build that repository. Given a leaf, subleaf, and index,
provide direct memory access to the parsed and cached per-CPU CPUID output.
** Long-term goal
Remove the need for drivers and other areas in the kernel to invoke direct
CPUID queries. Only one place in the kernel should be allowed to use the
CPUID instruction: the CPUID parser code.
** Implementation
Introduce CPUID_LEAF()/CPUID_LEAF_N() to build a compact CPUID storage
layout in the form:
struct leaf_0x0_0 leaf_0x0_0[1];
struct leaf_parse_info leaf_0x0_0_info;
struct leaf_0x1_0 leaf_0x1_0[1];
struct leaf_parse_info leaf_0x0_0_info;
struct leaf_0x4_n leaf_0x4_n[8];
struct leaf_parse_info leaf_0x4_n_info;
...
where each CPUID query stores its output at the designated leaf/subleaf
array and has an associated "CPUID query info" structure.
Embed the CPUID tables inside "struct cpuinfo_x86" to ensure early-boot and
per-CPU access through the CPUs capability structures.
Use an array of CPUID output storage entries for each leaf/subleaf
combination to accommodate leaves which produce the same output format for
a large subleaf range. This is typical for CPUID leaves enumerating
hierarchical objects; e.g. CPUID(0x4) cache topology enumeration,
CPUID(0xd) XSAVE enumeration, and CPUID(0x12) SGX Enclave Page Cache
enumeration.
** New CPUID APIs
Assuming a CPU capability structure 'c', provide macros to access the
parsed and cached CPUID leaf/subleaf output. These macros resolve to a
compile-time tokenization that ensures type-safety:
const struct leaf_0x7_0 *l7_0;
l7_0 = cpuid_subleaf(c, 0x7, 0);
| | └────────┐
| └─────────┐ |
* * *
&c.cpuid.leaf_0x7_0[0]
For CPUID leaves with multiple subleaves having the same output format,
provide the APIs:
const struct leaf_0x4_n *l4_0, *l4_1;
l4_0 = cpuid_subleaf_n(c, 0x4, 0);
| | └──────────┐
| └─────────┐ |
* * v
&c.cpuid.leaf_0x4_n[0]
l4_1 = cpuid_subleaf_n(c, 0x4, 1);
| | └──────────┐
| └─────────┐ |
* * v
&c.cpuid.leaf_0x4_n[1]
where the indices 0, 1, n above can be passed dynamically; e.g., in an
enumeration for loop.
Add a clear rationale on why call sites should use the these new APIs
instead of directly invoking CPUID.
** Next steps
For now, define cached parse entries for CPUID(0x0) and CPUID(0x1).
Generic parser logic to fill the CPUID tables, along with more CPUID leaves
support, will be added next.
Suggested-by: Thomas Gleixner <tglx@kernel.org> # CPUID data model
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> # x86-cpuid-db schema
Suggested-by: Borislav Petkov <bp@alien8.de> # Early CPUID centralization drafts
Suggested-by: Ingo Molnar <mingo@kernel.org> # CPUID headers restructuring
Suggested-by: Sean Christopherson <seanjc@google.com> # cpuid_subleaf_n() APIs
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/all/20260327021645.555257-1-darwi@linutronix.de
Link: https://lore.kernel.org/all/874ixernra.ffs@tglx
Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db
Link: https://lore.kernel.org/all/aBnSgu_JyEi8fvog@gmail.com
Link: https://lore.kernel.org/all/aJ9TbaNMgaplKSbH@google.com
2026-03-27 03:15:22 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2018-02-13 13:22:08 -06:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2020-05-05 15:36:17 -07:00
|
|
|
|
2015-01-23 18:45:43 +00:00
|
|
|
|
|
|
|
|
|
2020-05-05 15:36:17 -07:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2022-01-31 15:01:09 -08:00
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-08 23:10:52 +11:00
|
|
|
|
|
|
|
|
|
2011-10-12 17:46:33 -07:00
|
|
|
|
2018-08-24 10:03:50 -07:00
|
|
|
|
|
|
|
|
|
2017-11-14 07:42:56 -05:00
|
|
|
|
2016-10-28 01:22:25 -07:00
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-23 17:33:12 +08:00
|
|
|
|
2019-06-18 08:37:05 +00:00
|
|
|
|
2021-10-17 11:44:10 +02:00
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-04 15:07:32 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
2014-11-04 08:26:42 +00:00
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
|
|
|
|
|
2008-07-21 22:40:37 +05:30
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
2018-08-20 11:58:35 +02:00
|
|
|
|
2018-06-13 15:48:26 -07:00
|
|
|
|
2018-08-24 10:03:50 -07:00
|
|
|
|
2018-06-13 15:48:26 -07:00
|
|
|
|
|
|
|
|
|
2024-10-17 08:29:48 +02:00
|
|
|
|
|
|
|
|
|
2008-06-21 03:24:19 -07:00
|
|
|
|
2025-03-04 09:51:19 +01:00
|
|
|
|
2008-01-30 13:31:33 +01:00
|
|
|
|
2012-02-12 09:53:57 -08:00
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
2017-06-12 10:26:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-17 16:10:08 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
|
|
|
|
|
2017-07-17 16:10:07 -05:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2008-01-30 13:31:03 +01:00
|
|
|
|
2017-12-04 15:07:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-02 12:41:45 -07:00
|
|
|
|
2015-03-10 11:06:00 -07:00
|
|
|
|
|
|
|
|
|
2015-04-02 12:41:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-10 11:06:00 -07:00
|
|
|
|
2015-04-02 12:41:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-10 11:06:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-04 15:07:21 +01:00
|
|
|
|
2018-09-03 15:59:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2018-09-03 15:59:43 -07:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-20 08:56:13 -08:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2019-11-12 18:45:29 +01:00
|
|
|
|
|
|
|
|
|
2019-11-11 23:03:20 +01:00
|
|
|
|
2019-11-11 23:03:28 +01:00
|
|
|
|
2019-11-12 18:45:29 +01:00
|
|
|
|
2019-11-11 23:03:20 +01:00
|
|
|
|
|
|
|
|
|
2019-11-11 23:03:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-12 21:40:33 +01:00
|
|
|
|
2019-11-11 23:03:20 +01:00
|
|
|
|
2019-11-11 23:03:28 +01:00
|
|
|
|
|
|
|
|
|
2019-11-11 23:03:20 +01:00
|
|
|
|
2019-11-12 21:40:33 +01:00
|
|
|
|
2019-11-11 23:03:28 +01:00
|
|
|
|
|
|
|
|
|
2019-11-12 21:40:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-11 23:03:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2017-12-04 17:25:07 -08:00
|
|
|
|
2020-06-17 18:25:57 +02:00
|
|
|
|
2017-12-04 15:07:28 +01:00
|
|
|
|
|
|
|
|
|
2017-12-04 17:25:07 -08:00
|
|
|
|
|
|
|
|
|
2017-12-04 15:07:29 +01:00
|
|
|
|
2017-12-04 15:07:19 +01:00
|
|
|
|
2019-11-12 18:45:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-11 23:03:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-12 18:45:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-11 23:03:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-12 18:45:29 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2017-12-04 15:07:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2019-11-12 18:45:29 +01:00
|
|
|
|
2017-12-04 15:07:19 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2017-12-04 15:07:29 +01:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2019-04-14 18:00:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-03 11:52:42 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-03 11:52:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-03 14:12:56 -03:00
|
|
|
|
2018-03-13 18:48:05 +01:00
|
|
|
|
|
|
|
|
|
2025-01-23 14:07:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-13 18:48:05 +01:00
|
|
|
|
|
|
|
|
|
2023-06-23 14:14:05 +03:00
|
|
|
|
2018-03-13 18:48:04 +01:00
|
|
|
|
|
|
|
|
|
2020-05-28 16:13:52 -04:00
|
|
|
|
2025-01-23 14:07:39 -05:00
|
|
|
|
2008-01-30 13:31:03 +01:00
|
|
|
|
2009-09-09 19:22:48 +02:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2017-11-02 00:59:16 -07:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2017-11-02 00:59:16 -07:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2016-09-13 14:29:21 -07:00
|
|
|
|
2009-05-04 03:29:52 +04:00
|
|
|
|
2016-04-26 12:23:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-04 03:29:52 +04:00
|
|
|
|
2015-04-23 12:49:20 +02:00
|
|
|
|
2009-09-09 19:22:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-02 15:26:02 +02:00
|
|
|
|
2010-02-18 18:24:18 +01:00
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2012-03-12 14:55:55 +05:30
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2015-07-29 01:41:16 -04:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2015-07-29 01:41:16 -04:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2019-11-11 23:03:21 +01:00
|
|
|
|
2019-11-11 23:03:28 +01:00
|
|
|
|
|
|
|
|
|
2021-03-18 15:28:01 +01:00
|
|
|
|
2019-11-11 23:03:29 +01:00
|
|
|
|
|
|
|
|
|
2019-11-11 23:03:28 +01:00
|
|
|
|
|
|
|
|
|
2015-07-17 12:28:11 +02:00
|
|
|
|
2021-09-17 11:20:04 +02:00
|
|
|
|
2016-07-14 13:22:56 -07:00
|
|
|
|
2021-06-23 14:02:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 17:10:52 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-12 17:10:54 -07:00
|
|
|
|
|
|
|
|
|
2023-06-12 17:10:52 -07:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
|
|
|
|
|
2025-04-09 23:11:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-09 23:11:20 +02:00
|
|
|
|
2021-10-13 16:55:45 +02:00
|
|
|
|
|
|
|
|
|
2017-08-16 13:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-13 16:55:45 +02:00
|
|
|
|
2017-08-16 13:26:03 -07:00
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2017-11-02 00:59:10 -07:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2017-12-04 15:07:29 +01:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2020-05-28 16:13:50 -04:00
|
|
|
|
2008-01-30 13:32:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-07 13:37:45 +02:00
|
|
|
|
2015-03-05 19:19:02 -08:00
|
|
|
|
2017-12-04 15:07:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x86/percpu: Introduce const-qualified const_pcpu_hot to micro-optimize code generation
Some variables in pcpu_hot, currently current_task and top_of_stack
are actually per-thread variables implemented as per-CPU variables
and thus stable for the duration of the respective task. There is
already an attempt to eliminate redundant reads from these variables
using this_cpu_read_stable() asm macro, which hides the dependency
on the read memory address. However, the compiler has limited ability
to eliminate asm common subexpressions, so this approach results in a
limited success.
The solution is to allow more aggressive elimination by aliasing
pcpu_hot into a const-qualified const_pcpu_hot, and to read stable
per-CPU variables from this constant copy.
The current per-CPU infrastructure does not support reads from
const-qualified variables. However, when the compiler supports segment
qualifiers, it is possible to declare the const-aliased variable in
the relevant named address space. The compiler considers access to the
variable, declared in this way, as a read from a constant location,
and will optimize reads from the variable accordingly.
By implementing constant-qualified const_pcpu_hot, the compiler can
eliminate redundant reads from the constant variables, reducing the
number of loads from current_task from 3766 to 3217 on a test build,
a -14.6% reduction.
The reduction of loads translates to the following code savings:
text data bss dec hex filename
25,477,353 4389456 808452 30675261 1d4113d vmlinux-old.o
25,476,074 4389440 808452 30673966 1d40c2e vmlinux-new.o
representing a code size reduction of -1279 bytes.
[ mingo: Updated the changelog, EXPORT(const_pcpu_hot). ]
Co-developed-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20231020162004.135244-1-ubizjak@gmail.com
2023-10-20 18:19:20 +02:00
|
|
|
|
2025-03-03 11:52:43 -05:00
|
|
|
|
x86/percpu: Introduce const-qualified const_pcpu_hot to micro-optimize code generation
Some variables in pcpu_hot, currently current_task and top_of_stack
are actually per-thread variables implemented as per-CPU variables
and thus stable for the duration of the respective task. There is
already an attempt to eliminate redundant reads from these variables
using this_cpu_read_stable() asm macro, which hides the dependency
on the read memory address. However, the compiler has limited ability
to eliminate asm common subexpressions, so this approach results in a
limited success.
The solution is to allow more aggressive elimination by aliasing
pcpu_hot into a const-qualified const_pcpu_hot, and to read stable
per-CPU variables from this constant copy.
The current per-CPU infrastructure does not support reads from
const-qualified variables. However, when the compiler supports segment
qualifiers, it is possible to declare the const-aliased variable in
the relevant named address space. The compiler considers access to the
variable, declared in this way, as a read from a constant location,
and will optimize reads from the variable accordingly.
By implementing constant-qualified const_pcpu_hot, the compiler can
eliminate redundant reads from the constant variables, reducing the
number of loads from current_task from 3766 to 3217 on a test build,
a -14.6% reduction.
The reduction of loads translates to the following code savings:
text data bss dec hex filename
25,477,353 4389456 808452 30675261 1d4113d vmlinux-old.o
25,476,074 4389440 808452 30673966 1d40c2e vmlinux-new.o
representing a code size reduction of -1279 bytes.
[ mingo: Updated the changelog, EXPORT(const_pcpu_hot). ]
Co-developed-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20231020162004.135244-1-ubizjak@gmail.com
2023-10-20 18:19:20 +02:00
|
|
|
|
2025-03-03 11:52:43 -05:00
|
|
|
|
2015-03-05 19:19:02 -08:00
|
|
|
|
|
|
|
|
|
2022-05-07 13:37:45 +02:00
|
|
|
|
2017-11-02 00:59:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 09:40:23 +02:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2017-11-02 00:59:10 -07:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
2017-11-02 00:59:10 -07:00
|
|
|
|
2008-01-30 13:31:31 +01:00
|
|
|
|
|
|
|
|
|
2018-08-28 09:40:23 +02:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2021-09-29 15:02:14 -07:00
|
|
|
|
2008-01-30 13:31:03 +01:00
|
|
|
|
2024-02-28 23:20:32 +01:00
|
|
|
|
2016-12-09 19:29:11 +01:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2010-11-03 17:06:14 +01:00
|
|
|
|
2013-02-10 01:38:39 -05:00
|
|
|
|
2010-11-03 17:06:14 +01:00
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
|
|
|
|
|
2010-05-20 21:04:29 -05:00
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
2022-09-15 13:10:42 +02:00
|
|
|
|
2017-03-14 10:05:08 -07:00
|
|
|
|
2017-03-14 10:05:07 -07:00
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
2024-07-09 08:40:48 -07:00
|
|
|
|
|
|
|
|
|
2019-07-10 21:42:46 +02:00
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
2012-09-03 15:24:17 +02:00
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2009-05-07 16:54:11 -07:00
|
|
|
|
2008-01-30 13:31:39 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:40 +01:00
|
|
|
|
x86/asm: Cleanup prefetch primitives
This is based on a patch originally by hpa.
With the current improvements to the alternatives, we can simply use %P1
as a mem8 operand constraint and rely on the toolchain to generate the
proper instruction sizes. For example, on 32-bit, where we use an empty
old instruction we get:
apply_alternatives: feat: 6*32+8, old: (c104648b, len: 4), repl: (c195566c, len: 4)
c104648b: alt_insn: 90 90 90 90
c195566c: rpl_insn: 0f 0d 4b 5c
...
apply_alternatives: feat: 6*32+8, old: (c18e09b4, len: 3), repl: (c1955948, len: 3)
c18e09b4: alt_insn: 90 90 90
c1955948: rpl_insn: 0f 0d 08
...
apply_alternatives: feat: 6*32+8, old: (c1190cf9, len: 7), repl: (c1955a79, len: 7)
c1190cf9: alt_insn: 90 90 90 90 90 90 90
c1955a79: rpl_insn: 0f 0d 0d a0 d4 85 c1
all with the proper padding done depending on the size of the
replacement instruction the compiler generates.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: H. Peter Anvin <hpa@linux.intel.com>
2015-01-18 17:48:18 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:40 +01:00
|
|
|
|
2024-03-19 11:40:12 +01:00
|
|
|
|
2008-01-30 13:31:40 +01:00
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:40 +01:00
|
|
|
|
|
|
|
|
|
2024-03-19 11:40:12 +01:00
|
|
|
|
2008-01-30 13:31:40 +01:00
|
|
|
|
x86/asm: Cleanup prefetch primitives
This is based on a patch originally by hpa.
With the current improvements to the alternatives, we can simply use %P1
as a mem8 operand constraint and rely on the toolchain to generate the
proper instruction sizes. For example, on 32-bit, where we use an empty
old instruction we get:
apply_alternatives: feat: 6*32+8, old: (c104648b, len: 4), repl: (c195566c, len: 4)
c104648b: alt_insn: 90 90 90 90
c195566c: rpl_insn: 0f 0d 4b 5c
...
apply_alternatives: feat: 6*32+8, old: (c18e09b4, len: 3), repl: (c1955948, len: 3)
c18e09b4: alt_insn: 90 90 90
c1955948: rpl_insn: 0f 0d 08
...
apply_alternatives: feat: 6*32+8, old: (c1190cf9, len: 7), repl: (c1955a79, len: 7)
c1190cf9: alt_insn: 90 90 90 90 90 90 90
c1955a79: rpl_insn: 0f 0d 0d a0 d4 85 c1
all with the proper padding done depending on the size of the
replacement instruction the compiler generates.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: H. Peter Anvin <hpa@linux.intel.com>
2015-01-18 17:48:18 +01:00
|
|
|
|
2008-01-30 13:31:40 +01:00
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-03 13:40:22 +02:00
|
|
|
|
2008-01-30 13:31:40 +01:00
|
|
|
|
2024-03-19 11:40:12 +01:00
|
|
|
|
x86/asm: Cleanup prefetch primitives
This is based on a patch originally by hpa.
With the current improvements to the alternatives, we can simply use %P1
as a mem8 operand constraint and rely on the toolchain to generate the
proper instruction sizes. For example, on 32-bit, where we use an empty
old instruction we get:
apply_alternatives: feat: 6*32+8, old: (c104648b, len: 4), repl: (c195566c, len: 4)
c104648b: alt_insn: 90 90 90 90
c195566c: rpl_insn: 0f 0d 4b 5c
...
apply_alternatives: feat: 6*32+8, old: (c18e09b4, len: 3), repl: (c1955948, len: 3)
c18e09b4: alt_insn: 90 90 90
c1955948: rpl_insn: 0f 0d 08
...
apply_alternatives: feat: 6*32+8, old: (c1190cf9, len: 7), repl: (c1955a79, len: 7)
c1190cf9: alt_insn: 90 90 90 90 90 90 90
c1955a79: rpl_insn: 0f 0d 0d a0 d4 85 c1
all with the proper padding done depending on the size of the
replacement instruction the compiler generates.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: H. Peter Anvin <hpa@linux.intel.com>
2015-01-18 17:48:18 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:40 +01:00
|
|
|
|
|
|
|
|
|
2015-03-10 11:05:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-02 00:59:11 -07:00
|
|
|
|
|
|
|
|
|
2017-11-02 00:59:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:57 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2015-03-10 11:05:59 -07:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2008-01-30 13:31:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-21 14:05:06 -04:00
|
|
|
|
2023-03-16 22:21:03 +00:00
|
|
|
|
2024-03-04 00:33:33 -08:00
|
|
|
|
2024-03-21 14:05:06 -04:00
|
|
|
|
2023-03-16 22:21:03 +00:00
|
|
|
|
2008-01-30 13:31:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 05:18:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
|
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
|
|
|
|
|
2017-03-06 17:17:18 +03:00
|
|
|
|
2017-07-17 01:59:52 +03:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2008-02-21 04:24:40 +01:00
|
|
|
|
2025-03-03 13:31:11 -05:00
|
|
|
|
2008-01-30 13:31:27 +01:00
|
|
|
|
2008-04-14 00:24:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-20 01:16:26 -07:00
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:40 +02:00
|
|
|
|
2023-08-14 10:18:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-14 10:18:40 +02:00
|
|
|
|
2023-08-14 10:18:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-17 17:10:46 -05:00
|
|
|
|
2026-02-19 12:11:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-13 18:28:30 +02:00
|
|
|
|
2024-06-13 10:26:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-25 14:17:39 +02:00
|
|
|
|
2017-06-13 18:28:30 +02:00
|
|
|
|
2023-08-05 00:06:43 +02:00
|
|
|
|
2023-07-25 14:17:39 +02:00
|
|
|
|
2017-06-13 18:28:30 +02:00
|
|
|
|
2009-09-16 11:33:40 +02:00
|
|
|
|
2012-03-28 18:11:12 +01:00
|
|
|
|
2018-12-28 00:36:03 -08:00
|
|
|
|
2019-10-29 14:13:49 -07:00
|
|
|
|
2012-03-28 18:11:12 +01:00
|
|
|
|
|
|
|
|
|
2013-02-09 23:08:07 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-28 18:11:12 +01:00
|
|
|
|
2022-03-08 16:30:47 +01:00
|
|
|
|
2026-05-13 22:06:01 +02:00
|
|
|
|
2023-01-09 07:35:50 -08:00
|
|
|
|
2023-01-09 07:35:51 -08:00
|
|
|
|
x86/bugs, kvm: Introduce boot-time control of L1TF mitigations
Introduce the 'l1tf=' kernel command line option to allow for boot-time
switching of mitigation that is used on processors affected by L1TF.
The possible values are:
full
Provides all available mitigations for the L1TF vulnerability. Disables
SMT and enables all mitigations in the hypervisors. SMT control via
/sys/devices/system/cpu/smt/control is still possible after boot.
Hypervisors will issue a warning when the first VM is started in
a potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
full,force
Same as 'full', but disables SMT control. Implies the 'nosmt=force'
command line option. sysfs control of SMT and the hypervisor flush
control is disabled.
flush
Leaves SMT enabled and enables the conditional hypervisor mitigation.
Hypervisors will issue a warning when the first VM is started in a
potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
flush,nosmt
Disables SMT and enables the conditional hypervisor mitigation. SMT
control via /sys/devices/system/cpu/smt/control is still possible
after boot. If SMT is reenabled or flushing disabled at runtime
hypervisors will issue a warning.
flush,nowarn
Same as 'flush', but hypervisors will not warn when
a VM is started in a potentially insecure configuration.
off
Disables hypervisor mitigations and doesn't emit any warnings.
Default is 'flush'.
Let KVM adhere to these semantics, which means:
- 'lt1f=full,force' : Performe L1D flushes. No runtime control
possible.
- 'l1tf=full'
- 'l1tf-flush'
- 'l1tf=flush,nosmt' : Perform L1D flushes and warn on VM start if
SMT has been runtime enabled or L1D flushing
has been run-time enabled
- 'l1tf=flush,nowarn' : Perform L1D flushes and no warnings are emitted.
- 'l1tf=off' : L1D flushes are not performed and no warnings
are emitted.
KVM can always override the L1D flushing behavior using its 'vmentry_l1d_flush'
module parameter except when lt1f=full,force is set.
This makes KVM's private 'nosmt' option redundant, and as it is a bit
non-systematic anyway (this is something to control globally, not on
hypervisor level), remove that option.
Add the missing Documentation entry for the l1tf vulnerability sysfs file
while at it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20180713142323.202758176@linutronix.de
2018-07-13 16:23:25 +02:00
|
|
|
|
x86/sme: Use percpu boolean to control WBINVD during kexec
TL;DR:
Prepare to unify how TDX and SME do cache flushing during kexec by
making a percpu boolean control whether to do the WBINVD.
-- Background --
On SME platforms, dirty cacheline aliases with and without encryption
bit can coexist, and the CPU can flush them back to memory in random
order. During kexec, the caches must be flushed before jumping to the
new kernel otherwise the dirty cachelines could silently corrupt the
memory used by the new kernel due to different encryption property.
TDX also needs a cache flush during kexec for the same reason. It would
be good to have a generic way to flush the cache instead of scattering
checks for each feature all around.
When SME is enabled, the kernel basically encrypts all memory including
the kernel itself and a simple memory write from the kernel could dirty
cachelines. Currently, the kernel uses WBINVD to flush the cache for
SME during kexec in two places:
1) the one in stop_this_cpu() for all remote CPUs when the kexec-ing CPU
stops them;
2) the one in the relocate_kernel() where the kexec-ing CPU jumps to the
new kernel.
-- Solution --
Unlike SME, TDX can only dirty cachelines when it is used (i.e., when
SEAMCALLs are performed). Since there are no more SEAMCALLs after the
aforementioned WBINVDs, leverage this for TDX.
To unify the approach for SME and TDX, use a percpu boolean to indicate
the cache may be in an incoherent state and needs flushing during kexec,
and set the boolean for SME. TDX can then leverage it.
While SME could use a global flag (since it's enabled at early boot and
enabled on all CPUs), the percpu flag fits TDX better:
The percpu flag can be set when a CPU makes a SEAMCALL, and cleared when
another WBINVD on the CPU obviates the need for a kexec-time WBINVD.
Saving kexec-time WBINVD is valuable, because there is an existing
race[*] where kexec could proceed while another CPU is active. WBINVD
could make this race worse, so it's worth skipping it when possible.
-- Side effect to SME --
Today the first WBINVD in the stop_this_cpu() is performed when SME is
*supported* by the platform, and the second WBINVD is done in
relocate_kernel() when SME is *activated* by the kernel. Make things
simple by changing to do the second WBINVD when the platform supports
SME. This allows the kernel to simply turn on this percpu boolean when
bringing up a CPU by checking whether the platform supports SME.
No other functional change intended.
[*] The aforementioned race:
During kexec native_stop_other_cpus() is called to stop all remote CPUs
before jumping to the new kernel. native_stop_other_cpus() firstly
sends normal REBOOT vector IPIs to stop remote CPUs and waits them to
stop. If that times out, it sends NMI to stop the CPUs that are still
alive. The race happens when native_stop_other_cpus() has to send NMIs
and could potentially result in the system hang (for more information
please see [1]).
Signed-off-by: Kai Huang <kai.huang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/kvm/b963fcd60abe26c7ec5dc20b42f1a2ebbcc72397.1750934177.git.kai.huang@intel.com/ [1]
Link: https://lore.kernel.org/all/20250901160930.1785244-3-pbonzini%40redhat.com
2025-09-01 18:09:25 +02:00
|
|
|
|
|
|
|
|
|
x86/bugs, kvm: Introduce boot-time control of L1TF mitigations
Introduce the 'l1tf=' kernel command line option to allow for boot-time
switching of mitigation that is used on processors affected by L1TF.
The possible values are:
full
Provides all available mitigations for the L1TF vulnerability. Disables
SMT and enables all mitigations in the hypervisors. SMT control via
/sys/devices/system/cpu/smt/control is still possible after boot.
Hypervisors will issue a warning when the first VM is started in
a potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
full,force
Same as 'full', but disables SMT control. Implies the 'nosmt=force'
command line option. sysfs control of SMT and the hypervisor flush
control is disabled.
flush
Leaves SMT enabled and enables the conditional hypervisor mitigation.
Hypervisors will issue a warning when the first VM is started in a
potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
flush,nosmt
Disables SMT and enables the conditional hypervisor mitigation. SMT
control via /sys/devices/system/cpu/smt/control is still possible
after boot. If SMT is reenabled or flushing disabled at runtime
hypervisors will issue a warning.
flush,nowarn
Same as 'flush', but hypervisors will not warn when
a VM is started in a potentially insecure configuration.
off
Disables hypervisor mitigations and doesn't emit any warnings.
Default is 'flush'.
Let KVM adhere to these semantics, which means:
- 'lt1f=full,force' : Performe L1D flushes. No runtime control
possible.
- 'l1tf=full'
- 'l1tf-flush'
- 'l1tf=flush,nosmt' : Perform L1D flushes and warn on VM start if
SMT has been runtime enabled or L1D flushing
has been run-time enabled
- 'l1tf=flush,nowarn' : Perform L1D flushes and no warnings are emitted.
- 'l1tf=off' : L1D flushes are not performed and no warnings
are emitted.
KVM can always override the L1D flushing behavior using its 'vmentry_l1d_flush'
module parameter except when lt1f=full,force is set.
This makes KVM's private 'nosmt' option redundant, and as it is a bit
non-systematic anyway (this is something to control globally, not on
hypervisor level), remove that option.
Add the missing Documentation entry for the l1tf vulnerability sysfs file
while at it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20180713142323.202758176@linutronix.de
2018-07-13 16:23:25 +02:00
|
|
|
|
|
|
|
|
|
2025-04-18 11:17:20 -05:00
|
|
|
|
x86/bugs, kvm: Introduce boot-time control of L1TF mitigations
Introduce the 'l1tf=' kernel command line option to allow for boot-time
switching of mitigation that is used on processors affected by L1TF.
The possible values are:
full
Provides all available mitigations for the L1TF vulnerability. Disables
SMT and enables all mitigations in the hypervisors. SMT control via
/sys/devices/system/cpu/smt/control is still possible after boot.
Hypervisors will issue a warning when the first VM is started in
a potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
full,force
Same as 'full', but disables SMT control. Implies the 'nosmt=force'
command line option. sysfs control of SMT and the hypervisor flush
control is disabled.
flush
Leaves SMT enabled and enables the conditional hypervisor mitigation.
Hypervisors will issue a warning when the first VM is started in a
potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
flush,nosmt
Disables SMT and enables the conditional hypervisor mitigation. SMT
control via /sys/devices/system/cpu/smt/control is still possible
after boot. If SMT is reenabled or flushing disabled at runtime
hypervisors will issue a warning.
flush,nowarn
Same as 'flush', but hypervisors will not warn when
a VM is started in a potentially insecure configuration.
off
Disables hypervisor mitigations and doesn't emit any warnings.
Default is 'flush'.
Let KVM adhere to these semantics, which means:
- 'lt1f=full,force' : Performe L1D flushes. No runtime control
possible.
- 'l1tf=full'
- 'l1tf-flush'
- 'l1tf=flush,nosmt' : Perform L1D flushes and warn on VM start if
SMT has been runtime enabled or L1D flushing
has been run-time enabled
- 'l1tf=flush,nowarn' : Perform L1D flushes and no warnings are emitted.
- 'l1tf=off' : L1D flushes are not performed and no warnings
are emitted.
KVM can always override the L1D flushing behavior using its 'vmentry_l1d_flush'
module parameter except when lt1f=full,force is set.
This makes KVM's private 'nosmt' option redundant, and as it is a bit
non-systematic anyway (this is something to control globally, not on
hypervisor level), remove that option.
Add the missing Documentation entry for the l1tf vulnerability sysfs file
while at it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20180713142323.202758176@linutronix.de
2018-07-13 16:23:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-18 22:04:08 +01:00
|
|
|
|
|
|
|
|
|
2025-01-08 14:24:43 -06:00
|
|
|
|
2019-02-18 22:04:08 +01:00
|
|
|
|
2019-02-20 09:40:40 +01:00
|
|
|
|
2019-02-18 22:04:08 +01:00
|
|
|
|
|
|
|
|
|
2023-08-09 15:05:00 +02:00
|
|
|
|
|
|
|
|
|
x86/barrier: Do not serialize MSR accesses on AMD
AMD does not have the requirement for a synchronization barrier when
acccessing a certain group of MSRs. Do not incur that unnecessary
penalty there.
There will be a CPUID bit which explicitly states that a MFENCE is not
needed. Once that bit is added to the APM, this will be extended with
it.
While at it, move to processor.h to avoid include hell. Untangling that
file properly is a matter for another day.
Some notes on the performance aspect of why this is relevant, courtesy
of Kishon VijayAbraham <Kishon.VijayAbraham@amd.com>:
On a AMD Zen4 system with 96 cores, a modified ipi-bench[1] on a VM
shows x2AVIC IPI rate is 3% to 4% lower than AVIC IPI rate. The
ipi-bench is modified so that the IPIs are sent between two vCPUs in the
same CCX. This also requires to pin the vCPU to a physical core to
prevent any latencies. This simulates the use case of pinning vCPUs to
the thread of a single CCX to avoid interrupt IPI latency.
In order to avoid run-to-run variance (for both x2AVIC and AVIC), the
below configurations are done:
1) Disable Power States in BIOS (to prevent the system from going to
lower power state)
2) Run the system at fixed frequency 2500MHz (to prevent the system
from increasing the frequency when the load is more)
With the above configuration:
*) Performance measured using ipi-bench for AVIC:
Average Latency: 1124.98ns [Time to send IPI from one vCPU to another vCPU]
Cumulative throughput: 42.6759M/s [Total number of IPIs sent in a second from
48 vCPUs simultaneously]
*) Performance measured using ipi-bench for x2AVIC:
Average Latency: 1172.42ns [Time to send IPI from one vCPU to another vCPU]
Cumulative throughput: 40.9432M/s [Total number of IPIs sent in a second from
48 vCPUs simultaneously]
From above, x2AVIC latency is ~4% more than AVIC. However, the expectation is
x2AVIC performance to be better or equivalent to AVIC. Upon analyzing
the perf captures, it is observed significant time is spent in
weak_wrmsr_fence() invoked by x2apic_send_IPI().
With the fix to skip weak_wrmsr_fence()
*) Performance measured using ipi-bench for x2AVIC:
Average Latency: 1117.44ns [Time to send IPI from one vCPU to another vCPU]
Cumulative throughput: 42.9608M/s [Total number of IPIs sent in a second from
48 vCPUs simultaneously]
Comparing the performance of x2AVIC with and without the fix, it can be seen
the performance improves by ~4%.
Performance captured using an unmodified ipi-bench using the 'mesh-ipi' option
with and without weak_wrmsr_fence() on a Zen4 system also showed significant
performance improvement without weak_wrmsr_fence(). The 'mesh-ipi' option ignores
CCX or CCD and just picks random vCPU.
Average throughput (10 iterations) with weak_wrmsr_fence(),
Cumulative throughput: 4933374 IPI/s
Average throughput (10 iterations) without weak_wrmsr_fence(),
Cumulative throughput: 6355156 IPI/s
[1] https://github.com/bytedance/kvm-utils/tree/master/microbenchmark/ipi-bench
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230622095212.20940-1-bp@alien8.de
2023-10-27 14:24:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-22 22:26:29 -07:00
|
|
|
|
