Skip to content

Commit 9e536c8

Browse files
torvaldstorvalds
committed
Merge tag 'x86_misc_for_v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull misc x86 fixes fromm Borislav Petkov: - Ratelimit the message about writes to unrecognized MSRs so that they don't spam the console log (Chris Down) - Document how the /proc/cpuinfo machinery works for future reference (Kyung Min Park, Ricardo Neri and Dave Hansen) - Correct the current NMI's duration calculation (Libing Zhou) * tag 'x86_misc_for_v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/nmi: Fix nmi_handle() duration miscalculation Documentation/x86: Add documentation for /proc/cpuinfo feature flags x86/msr: Make source of unrecognised MSR writes unambiguous x86/msr: Prevent userspace MSR access from dominating the console
2 parents ac74075 + f94c91f commit 9e536c8

4 files changed

Lines changed: 173 additions & 6 deletions

File tree

‎Documentation/x86/cpuinfo.rst‎

Lines changed: 155 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,155 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
3+
=================
4+
x86 Feature Flags
5+
=================
6+
7+
Introduction
8+
============
9+
10+
On x86, flags appearing in /proc/cpuinfo have an X86_FEATURE definition
11+
in arch/x86/include/asm/cpufeatures.h. If the kernel cares about a feature
12+
or KVM want to expose the feature to a KVM guest, it can and should have
13+
an X86_FEATURE_* defined. These flags represent hardware features as
14+
well as software features.
15+
16+
If users want to know if a feature is available on a given system, they
17+
try to find the flag in /proc/cpuinfo. If a given flag is present, it
18+
means that the kernel supports it and is currently making it available.
19+
If such flag represents a hardware feature, it also means that the
20+
hardware supports it.
21+
22+
If the expected flag does not appear in /proc/cpuinfo, things are murkier.
23+
Users need to find out the reason why the flag is missing and find the way
24+
how to enable it, which is not always easy. There are several factors that
25+
can explain missing flags: the expected feature failed to enable, the feature
26+
is missing in hardware, platform firmware did not enable it, the feature is
27+
disabled at build or run time, an old kernel is in use, or the kernel does
28+
not support the feature and thus has not enabled it. In general, /proc/cpuinfo
29+
shows features which the kernel supports. For a full list of CPUID flags
30+
which the CPU supports, use tools/arch/x86/kcpuid.
31+
32+
How are feature flags created?
33+
==============================
34+
35+
a: Feature flags can be derived from the contents of CPUID leaves.
36+
------------------------------------------------------------------
37+
These feature definitions are organized mirroring the layout of CPUID
38+
leaves and grouped in words with offsets as mapped in enum cpuid_leafs
39+
in cpufeatures.h (see arch/x86/include/asm/cpufeatures.h for details).
40+
If a feature is defined with a X86_FEATURE_<name> definition in
41+
cpufeatures.h, and if it is detected at run time, the flags will be
42+
displayed accordingly in /proc/cpuinfo. For example, the flag "avx2"
43+
comes from X86_FEATURE_AVX2 in cpufeatures.h.
44+
45+
b: Flags can be from scattered CPUID-based features.
46+
----------------------------------------------------
47+
Hardware features enumerated in sparsely populated CPUID leaves get
48+
software-defined values. Still, CPUID needs to be queried to determine
49+
if a given feature is present. This is done in init_scattered_cpuid_features().
50+
For instance, X86_FEATURE_CQM_LLC is defined as 11*32 + 0 and its presence is
51+
checked at runtime in the respective CPUID leaf [EAX=f, ECX=0] bit EDX[1].
52+
53+
The intent of scattering CPUID leaves is to not bloat struct
54+
cpuinfo_x86.x86_capability[] unnecessarily. For instance, the CPUID leaf
55+
[EAX=7, ECX=0] has 30 features and is dense, but the CPUID leaf [EAX=7, EAX=1]
56+
has only one feature and would waste 31 bits of space in the x86_capability[]
57+
array. Since there is a struct cpuinfo_x86 for each possible CPU, the wasted
58+
memory is not trivial.
59+
60+
c: Flags can be created synthetically under certain conditions for hardware features.
61+
-------------------------------------------------------------------------------------
62+
Examples of conditions include whether certain features are present in
63+
MSR_IA32_CORE_CAPS or specific CPU models are identified. If the needed
64+
conditions are met, the features are enabled by the set_cpu_cap or
65+
setup_force_cpu_cap macros. For example, if bit 5 is set in MSR_IA32_CORE_CAPS,
66+
the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and
67+
"split_lock_detect" will be displayed. The flag "ring3mwait" will be
68+
displayed only when running on INTEL_FAM6_XEON_PHI_[KNL|KNM] processors.
69+
70+
d: Flags can represent purely software features.
71+
------------------------------------------------
72+
These flags do not represent hardware features. Instead, they represent a
73+
software feature implemented in the kernel. For example, Kernel Page Table
74+
Isolation is purely software feature and its feature flag X86_FEATURE_PTI is
75+
also defined in cpufeatures.h.
76+
77+
Naming of Flags
78+
===============
79+
80+
The script arch/x86/kernel/cpu/mkcapflags.sh processes the
81+
#define X86_FEATURE_<name> from cpufeatures.h and generates the
82+
x86_cap/bug_flags[] arrays in kernel/cpu/capflags.c. The names in the
83+
resulting x86_cap/bug_flags[] are used to populate /proc/cpuinfo. The naming
84+
of flags in the x86_cap/bug_flags[] are as follows:
85+
86+
a: The name of the flag is from the string in X86_FEATURE_<name> by default.
87+
----------------------------------------------------------------------------
88+
By default, the flag <name> in /proc/cpuinfo is extracted from the respective
89+
X86_FEATURE_<name> in cpufeatures.h. For example, the flag "avx2" is from
90+
X86_FEATURE_AVX2.
91+
92+
b: The naming can be overridden.
93+
--------------------------------
94+
If the comment on the line for the #define X86_FEATURE_* starts with a
95+
double-quote character (""), the string inside the double-quote characters
96+
will be the name of the flags. For example, the flag "sse4_1" comes from
97+
the comment "sse4_1" following the X86_FEATURE_XMM4_1 definition.
98+
99+
There are situations in which overriding the displayed name of the flag is
100+
needed. For instance, /proc/cpuinfo is a userspace interface and must remain
101+
constant. If, for some reason, the naming of X86_FEATURE_<name> changes, one
102+
shall override the new naming with the name already used in /proc/cpuinfo.
103+
104+
c: The naming override can be "", which means it will not appear in /proc/cpuinfo.
105+
----------------------------------------------------------------------------------
106+
The feature shall be omitted from /proc/cpuinfo if it does not make sense for
107+
the feature to be exposed to userspace. For example, X86_FEATURE_ALWAYS is
108+
defined in cpufeatures.h but that flag is an internal kernel feature used
109+
in the alternative runtime patching functionality. So, its name is overridden
110+
with "". Its flag will not appear in /proc/cpuinfo.
111+
112+
Flags are missing when one or more of these happen
113+
==================================================
114+
115+
a: The hardware does not enumerate support for it.
116+
--------------------------------------------------
117+
For example, when a new kernel is running on old hardware or the feature is
118+
not enabled by boot firmware. Even if the hardware is new, there might be a
119+
problem enabling the feature at run time, the flag will not be displayed.
120+
121+
b: The kernel does not know about the flag.
122+
-------------------------------------------
123+
For example, when an old kernel is running on new hardware.
124+
125+
c: The kernel disabled support for it at compile-time.
126+
------------------------------------------------------
127+
For example, if 5-level-paging is not enabled when building (i.e.,
128+
CONFIG_X86_5LEVEL is not selected) the flag "la57" will not show up [#f1]_.
129+
Even though the feature will still be detected via CPUID, the kernel disables
130+
it by clearing via setup_clear_cpu_cap(X86_FEATURE_LA57).
131+
132+
d: The feature is disabled at boot-time.
133+
----------------------------------------
134+
A feature can be disabled either using a command-line parameter or because
135+
it failed to be enabled. The command-line parameter clearcpuid= can be used
136+
to disable features using the feature number as defined in
137+
/arch/x86/include/asm/cpufeatures.h. For instance, User Mode Instruction
138+
Protection can be disabled using clearcpuid=514. The number 514 is calculated
139+
from #define X86_FEATURE_UMIP (16*32 + 2).
140+
141+
In addition, there exists a variety of custom command-line parameters that
142+
disable specific features. The list of parameters includes, but is not limited
143+
to, nofsgsbase, nosmap, and nosmep. 5-level paging can also be disabled using
144+
"no5lvl". SMAP and SMEP are disabled with the aforementioned parameters,
145+
respectively.
146+
147+
e: The feature was known to be non-functional.
148+
----------------------------------------------
149+
The feature was known to be non-functional because a dependency was
150+
missing at runtime. For example, AVX flags will not show up if XSAVE feature
151+
is disabled since they depend on XSAVE feature. Another example would be broken
152+
CPUs and them missing microcode patches. Due to that, the kernel decides not to
153+
enable a feature.
154+
155+
.. [#f1] 5-level paging uses linear address of 57 bits.

‎Documentation/x86/index.rst‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@ x86-specific Documentation
99
:numbered:
1010

1111
boot
12+
cpuinfo
1213
topology
1314
exception-tables
1415
kernel-stacks

‎arch/x86/kernel/msr.c‎

Lines changed: 15 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -80,18 +80,30 @@ static ssize_t msr_read(struct file *file, char __user *buf,
8080

8181
static int filter_write(u32 reg)
8282
{
83+
/*
84+
* MSRs writes usually happen all at once, and can easily saturate kmsg.
85+
* Only allow one message every 30 seconds.
86+
*
87+
* It's possible to be smarter here and do it (for example) per-MSR, but
88+
* it would certainly be more complex, and this is enough at least to
89+
* avoid saturating the ring buffer.
90+
*/
91+
static DEFINE_RATELIMIT_STATE(fw_rs, 30 * HZ, 1);
92+
8393
switch (allow_writes) {
8494
case MSR_WRITES_ON: return 0;
8595
case MSR_WRITES_OFF: return -EPERM;
8696
default: break;
8797
}
8898

99+
if (!__ratelimit(&fw_rs))
100+
return 0;
101+
89102
if (reg == MSR_IA32_ENERGY_PERF_BIAS)
90103
return 0;
91104

92-
pr_err_ratelimited("Write to unrecognized MSR 0x%x by %s\n"
93-
"Please report to x86@kernel.org\n",
94-
reg, current->comm);
105+
pr_err("Write to unrecognized MSR 0x%x by %s (pid: %d). Please report to x86@kernel.org.\n",
106+
reg, current->comm, current->pid);
95107

96108
return 0;
97109
}

‎arch/x86/kernel/nmi.c‎

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -102,20 +102,19 @@ fs_initcall(nmi_warning_debugfs);
102102

103103
static void nmi_check_duration(struct nmiaction *action, u64 duration)
104104
{
105-
u64 whole_msecs = READ_ONCE(action->max_duration);
106105
int remainder_ns, decimal_msecs;
107106

108107
if (duration < nmi_longest_ns || duration < action->max_duration)
109108
return;
110109

111110
action->max_duration = duration;
112111

113-
remainder_ns = do_div(whole_msecs, (1000 * 1000));
112+
remainder_ns = do_div(duration, (1000 * 1000));
114113
decimal_msecs = remainder_ns / 1000;
115114

116115
printk_ratelimited(KERN_INFO
117116
"INFO: NMI handler (%ps) took too long to run: %lld.%03d msecs\n",
118-
action->handler, whole_msecs, decimal_msecs);
117+
action->handler, duration, decimal_msecs);
119118
}
120119

121120
static int nmi_handle(unsigned int type, struct pt_regs *regs)

0 commit comments

Comments
 (0)