Re: [PATCH v2] Documentation/x86: Add documentation for /proc/cpuinfo feature flags
On Sun, 2020-08-30 at 13:50 +0200, Borislav Petkov wrote: > On Fri, Aug 28, 2020 at 03:30:32PM -0700, Kyung Min Park wrote: > > Should I mention the tool specifically although the tool is WIP? > > Well, if you wanna look at it that way, the whole kernel is > constantly > and forever WIP. :-) > > Also, if there's some functionality missing, pointing to it might > make > people send patches. That makes sense. :) > > As you commented previously, should I use > > tools/arch/x86/tools/cpuid/cpuid as the future tool and its > > location? > > Yeah, let's just drop the second "tools", i.e., > > tools/arch/x86/kcpuid/ > > or so should be good enough. > > Thx. Sure, I'll update in the next patch. Thank you for clarifying.
Re: [PATCH v2] Documentation/x86: Add documentation for /proc/cpuinfo feature flags
On Fri, Aug 28, 2020 at 03:30:32PM -0700, Kyung Min Park wrote: > Should I mention the tool specifically although the tool is WIP? Well, if you wanna look at it that way, the whole kernel is constantly and forever WIP. :-) Also, if there's some functionality missing, pointing to it might make people send patches. > As you commented previously, should I use > tools/arch/x86/tools/cpuid/cpuid as the future tool and its location? Yeah, let's just drop the second "tools", i.e., tools/arch/x86/kcpuid/ or so should be good enough. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v2] Documentation/x86: Add documentation for /proc/cpuinfo feature flags
Hi Boris, On Fri, 2020-08-28 at 20:42 +0200, Borislav Petkov wrote: > On Mon, Aug 24, 2020 at 11:04:12AM -0700, Kyung Min Park wrote: > > +If the expected flag does not appear in /proc/cpuinfo, things are > > murkier. > > +Users need to find out the reason why the flag is missing and find > > the way > > +how to enable it, which is not always easy. There are several > > factors that > > +can explain missing flags: the expected feature failed to enable, > > the feature > > +is missing in hardware, platform firmware did not enable it, the > > feature is > > +disabled at build or run time, an old kernel is in use, or the > > kernel does > > +not support the feature and thus has not enabled it. In general, > > /proc/cpuinfo > > +shows features which the kernel supports. > > + > > +For a full list of CPUID flags which the CPU supports, the users > > may use > > +tools like http://www.etallen.com/cpuid.html (which is not updated > > with > > +kernel releases) or other custom tools that read CPUID. > > I guess this should talk only about our own kcpuid tool since we > wanna > do that now, right? Should I mention the tool specifically although the tool is WIP? As you commented previously, should I use tools/arch/x86/tools/cpuid/cpuid as the future tool and its location? Or do you want it to be mentioned in the future tense without specifying the tool name and location? > > ... > > > +c: 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 via cleared by setup_clear_cpu_cap(X86_FEATURE_LA57). > > "... disables it by clearing... " Sure, let me fix it. > > > +d: 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 > > +/arch/x86/include/asm/cpufeatures.h. For instance, User Mode > > Instruction > > +Protection can be disabled using clearcpuid=514. The number 514 is > > calculated > > +from #define X86_FEATURE_UMIP (16*32 + 2). > > + > > +In addition, there exists a variety of custom command-line > > parameters that > > +disable specific features. The list of parameters includes, but is > > not limited > > +to, no5lvl, nosmap, and nosmep. > > You already give the separate example for "no5lvl" below so use > something else > above, say, "nofsgsbase", for example. You're right. Let me change it. > > > 5-level paging can also be disabled using > > +"no5lvl". SMAP and SMEP are disabled with the aforementioned > > parameters, > > +respectively. > > + > > +e: 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 CPUs and them missing microcode > patches > and due to that the kernel deciding not to enable a feature. Thank you for the comment. I'll add that too. > > But yap, all in all looks like a good idea. I'll take the next > version > after you've fixed those nitpicks. > > Thx. Thanks Boris!
Re: [PATCH v2] Documentation/x86: Add documentation for /proc/cpuinfo feature flags
On Mon, Aug 24, 2020 at 11:04:12AM -0700, Kyung Min Park wrote: > +If the expected flag does not appear in /proc/cpuinfo, things are murkier. > +Users need to find out the reason why the flag is missing and find the way > +how to enable it, which is not always easy. There are several factors that > +can explain missing flags: the expected feature failed to enable, the feature > +is missing in hardware, platform firmware did not enable it, the feature is > +disabled at build or run time, an old kernel is in use, or the kernel does > +not support the feature and thus has not enabled it. In general, > /proc/cpuinfo > +shows features which the kernel supports. > + > +For a full list of CPUID flags which the CPU supports, the users may use > +tools like http://www.etallen.com/cpuid.html (which is not updated with > +kernel releases) or other custom tools that read CPUID. I guess this should talk only about our own kcpuid tool since we wanna do that now, right? ... > +c: 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 via cleared by setup_clear_cpu_cap(X86_FEATURE_LA57). "... disables it by clearing... " > +d: 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 > +/arch/x86/include/asm/cpufeatures.h. For instance, User Mode Instruction > +Protection can be disabled using clearcpuid=514. The number 514 is calculated > +from #define X86_FEATURE_UMIP (16*32 + 2). > + > +In addition, there exists a variety of custom command-line parameters that > +disable specific features. The list of parameters includes, but is not > limited > +to, no5lvl, nosmap, and nosmep. You already give the separate example for "no5lvl" below so use something else above, say, "nofsgsbase", for example. > 5-level paging can also be disabled using > +"no5lvl". SMAP and SMEP are disabled with the aforementioned parameters, > +respectively. > + > +e: 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 CPUs and them missing microcode patches and due to that the kernel deciding not to enable a feature. But yap, all in all looks like a good idea. I'll take the next version after you've fixed those nitpicks. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[PATCH v2] Documentation/x86: Add documentation for /proc/cpuinfo feature flags
/proc/cpuinfo shows features which the kernel supports. Some of these flags are derived from CPUID, and others are derived from other sources, including some that are entirely software-based. Currently, there is not any documentation in the kernel about how /proc/cpuinfo flags are generated and what it means when they are missing. Add documentation for /proc/cpuinfo feature flags enumeration. Document how and when x86 feature flags are used. Also discuss what their presence or absence mean for the kernel and users. Reviewed-by: Tony Luck Suggested-by: Dave Hansen Co-developed-by: Ricardo Neri Signed-off-by: Ricardo Neri Signed-off-by: Kyung Min Park --- ChangeLog: - Change from v1 to v2: 1. Removed patches of adding feature flags (TSXLDTRK, SERIALIZE) from this patchset. 2. Removed the cover letter. 3. Some change of wording in Documentation/x86/cpuinfo.rst as suggested by Borislav Petkov. 4. Add the explanation of the feature flag usage for KVM as suggested by Tony Luck. --- Documentation/x86/cpuinfo.rst | 156 ++ Documentation/x86/index.rst | 1 + 2 files changed, 157 insertions(+) create mode 100644 Documentation/x86/cpuinfo.rst diff --git a/Documentation/x86/cpuinfo.rst b/Documentation/x86/cpuinfo.rst new file mode 100644 index ..b1a88dd14a8d --- /dev/null +++ b/Documentation/x86/cpuinfo.rst @@ -0,0 +1,156 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +x86 Feature Flags += + +Introduction + + +On x86, flags appearing in /proc/cpuinfo have an X86_FEATURE definition +in arch/x86/include/asm/cpufeatures.h. If the kernel cares about a feature +or KVM want to expose the feature to a KVM guest, it can and should have +an X86_FEATURE_* defined. These flags represent hardware features as +well as software features. + +If users want to know if a feature is available on a given system, they +try to find the flag in /proc/cpuinfo. If a given flag is present, it +means that the kernel supports it and is currently making it available. +If such flag represents a hardware feature, it also means that the +hardware supports it. + +If the expected flag does not appear in /proc/cpuinfo, things are murkier. +Users need to find out the reason why the flag is missing and find the way +how to enable it, which is not always easy. There are several factors that +can explain missing flags: the expected feature failed to enable, the feature +is missing in hardware, platform firmware did not enable it, the feature is +disabled at build or run time, an old kernel is in use, or the kernel does +not support the feature and thus has not enabled it. In general, /proc/cpuinfo +shows features which the kernel supports. + +For a full list of CPUID flags which the CPU supports, the users may use +tools like http://www.etallen.com/cpuid.html (which is not updated with +kernel releases) or other custom tools that read CPUID. + +How are feature flags created? +== + +a: 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). +If a feature is defined with a X86_FEATURE_ definition in +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. + +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(). +For instance, X86_FEATURE_CQM_LLC is defined as 11*32 + 0 and its presence is +checked at runtime in the respective CPUID leaf [EAX=f, ECX=0] bit EDX[1]. + +The intent of scattering CPUID leaves is to not bloat struct +cpuinfo_x86.x86_capability[] unnecessarily. For instance, the CPUID leaf +[EAX=7, ECX=0] has 30 features and is dense, but the CPUID leaf [EAX=7, EAX=1] +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. +- +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 +setup_force_cpu_cap macros. For example, if bit 5 is set in MSR_IA32_CORE_CAPS, +the
