Commit 254a6d14 authored by Borislav Petkov (AMD)'s avatar Borislav Petkov (AMD) Committed by Ingo Molnar
Browse files

Documentation/x86: Zap the subsection letters 



The subsections already have numbering - no need for the letters too.

Zap the latter.

Signed-off-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20250409111435.GEZ_ZWmz3_lkP8S9Lb@fat_crate.local
parent af76f7d5

Documentation/arch/x86/cpuinfo.rst

+29 −22
Original line number Diff line number Diff line
@@ -79,8 +79,9 @@ feature flags. 
How are feature flags created?

==============================



a: Feature flags can be derived from the contents of CPUID leaves.

------------------------------------------------------------------

Feature flags can be derived from the contents of CPUID leaves

--------------------------------------------------------------



These feature definitions are organized mirroring the layout of CPUID

leaves and grouped in words with offsets as mapped in enum cpuid_leafs

in cpufeatures.h (see arch/x86/include/asm/cpufeatures.h for details).
@@ -89,8 +90,9 @@ cpufeatures.h, and if it is detected at run time, the flags will be 
displayed accordingly in /proc/cpuinfo. For example, the flag "avx2"

comes from X86_FEATURE_AVX2 in cpufeatures.h.



b: Flags can be from scattered CPUID-based features.

----------------------------------------------------

Flags can be from scattered CPUID-based features

------------------------------------------------



Hardware features enumerated in sparsely populated CPUID leaves get

software-defined values. Still, CPUID needs to be queried to determine

if a given feature is present. This is done in init_scattered_cpuid_features().
@@ -104,8 +106,9 @@ has only one feature and would waste 31 bits of space in the x86_capability[] 
array. Since there is a struct cpuinfo_x86 for each possible CPU, the wasted

memory is not trivial.



c: Flags can be created synthetically under certain conditions for hardware features.

-------------------------------------------------------------------------------------

Flags can be created synthetically under certain conditions for hardware features

---------------------------------------------------------------------------------



Examples of conditions include whether certain features are present in

MSR_IA32_CORE_CAPS or specific CPU models are identified. If the needed

conditions are met, the features are enabled by the set_cpu_cap or
@@ -114,8 +117,8 @@ the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and 
"split_lock_detect" will be displayed. The flag "ring3mwait" will be

displayed only when running on INTEL_XEON_PHI_[KNL|KNM] processors.



d: Flags can represent purely software features.

------------------------------------------------

Flags can represent purely software features

--------------------------------------------

These flags do not represent hardware features. Instead, they represent a

software feature implemented in the kernel. For example, Kernel Page Table

Isolation is purely software feature and its feature flag X86_FEATURE_PTI is
@@ -130,8 +133,8 @@ x86_cap/bug_flags[] arrays in kernel/cpu/capflags.c. The names in the 
resulting x86_cap/bug_flags[] are used to populate /proc/cpuinfo. The naming

of flags in the x86_cap/bug_flags[] are as follows:



a: Flags do not appear by default in /proc/cpuinfo

--------------------------------------------------

Flags do not appear by default in /proc/cpuinfo

-----------------------------------------------



Feature flags are omitted by default from /proc/cpuinfo as it does not make

sense for the feature to be exposed to userspace in most cases. For example,
@@ -139,8 +142,8 @@ X86_FEATURE_ALWAYS is defined in cpufeatures.h but that flag is an internal 
kernel feature used in the alternative runtime patching functionality. So the

flag does not appear in /proc/cpuinfo.



b: Specify a flag name if absolutely needed

-------------------------------------------

Specify a flag name if absolutely needed

----------------------------------------



If the comment on the line for the #define X86_FEATURE_* starts with a

double-quote character (""), the string inside the double-quote characters
@@ -155,25 +158,28 @@ shall override the new naming with the name already used in /proc/cpuinfo. 
Flags are missing when one or more of these happen

==================================================



a: The hardware does not enumerate support for it.

--------------------------------------------------

The hardware does not enumerate support for it

----------------------------------------------



For example, when a new kernel is running on old hardware or the feature is

not enabled by boot firmware. Even if the hardware is new, there might be a

problem enabling the feature at run time, the flag will not be displayed.



b: The kernel does not know about the flag.

-------------------------------------------

The kernel does not know about the flag

---------------------------------------



For example, when an old kernel is running on new hardware.



c: The kernel disabled support for it at compile-time.

------------------------------------------------------

The kernel disabled support for it at compile-time

--------------------------------------------------



For example, if 5-level-paging is not enabled when building (i.e.,

CONFIG_X86_5LEVEL is not selected) the flag "la57" will not show up [#f1]_.

Even though the feature will still be detected via CPUID, the kernel disables

it by clearing via setup_clear_cpu_cap(X86_FEATURE_LA57).



d: The feature is disabled at boot-time.

----------------------------------------

The feature is disabled at boot-time

------------------------------------

A feature can be disabled either using a command-line parameter or because

it failed to be enabled. The command-line parameter clearcpuid= can be used

to disable features using the feature number as defined in
@@ -186,8 +192,9 @@ disable specific features. The list of parameters includes, but is not limited 
to, nofsgsbase, nosgx, noxsave, etc. 5-level paging can also be disabled using

"no5lvl".



e: The feature was known to be non-functional.

----------------------------------------------

The feature was known to be non-functional

------------------------------------------



The feature was known to be non-functional because a dependency was

missing at runtime. For example, AVX flags will not show up if XSAVE feature

is disabled since they depend on XSAVE feature. Another example would be broken