Currently, there isn't any documentation in the kernel about how
/proc/cpuinfo flags are generated and what it means when they are
missing. x86 maintainers have expressed objections on adding flags
for features without kernel use cases and that part of the reason is
the lack of documentation on the logic behind such flags.
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 Linux supports it. If such flag represents a hardware feature,
it also means that the hardware supports it. Therefore, it is not
sufficient to read CPUID to determine whether a hardware feature is
available. If the flag is missing in /proc/cpuinfo, users need to find
out the reason why the flag is missing and how to enable it, which is
not always easy.
/proc/cpuinfo should show all of the hardware features and bugs that any
application or end user might care about. Some of these flags are derived
from CPUID, and others are derived from other sources, including some that
are entirely software-based. Add documentation how features are created,
naming of the flags and when they are missing, what it means to users.
Include two instances of features for which there are not implemented
use cases in the kernel.
Patch 1 creates a new documentation for /proc/cpuinfo flags bits.
Patch 2 adds X86_FEATURE_SERIALIZE.
Patch 3 adds X86_FEATURE_TSXLDTRK.
This RFC series has been reviewed by Dave Hansen.
Kyung Min Park (2):
Documentation/x86: Add documentation for /proc/cpuinfo feature flags
x86/cpufeatures: Enumerate TSX suspend load address tracking
instructions
Ricardo Neri (1):
x86/cpufeatures: Add enumeration for SERIALIZE instruction
Documentation/x86/cpuinfo.rst | 152 +++++++++++++++++++++++++++++
Documentation/x86/index.rst | 1 +
arch/x86/include/asm/cpufeatures.h | 2 +
3 files changed, 155 insertions(+)
create mode 100644 Documentation/x86/cpuinfo.rst
--
2.17.1
On Wed, Jun 10, 2020 at 01:06:58PM -0700, Kyung Min Park wrote:
> Include two instances of features for which there are not implemented
> use cases in the kernel.
>
> Patch 1 creates a new documentation for /proc/cpuinfo flags bits.
> Patch 2 adds X86_FEATURE_SERIALIZE.
> Patch 3 adds X86_FEATURE_TSXLDTRK.
>
> This RFC series has been reviewed by Dave Hansen.
Yeah, and he and I talked about this on IRC. If you really want to dump
CPUID to see what's there, we should do a userspace tool in tools/ or
even use the ones which are already out there: x86info, cpuid, ...
Just adding X86_FEATURE_* flags without usage in the kernel makes no
sense and will cause unnecessary bloat and doesn't help one bit because
userspace simply calls CPUID directly.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Jun 10, 2020 at 01:06:58PM -0700, Kyung Min Park wrote:
> This RFC series has been reviewed by Dave Hansen.
Then why isn't there a "Reviewed-by:" line with his name on it on the
patches?
Come on, you all know how to do this properly...
On 6/10/20 1:35 PM, Borislav Petkov wrote:
> On Wed, Jun 10, 2020 at 01:06:58PM -0700, Kyung Min Park wrote:
>> Include two instances of features for which there are not implemented
>> use cases in the kernel.
>>
>> Patch 1 creates a new documentation for /proc/cpuinfo flags bits.
>> Patch 2 adds X86_FEATURE_SERIALIZE.
>> Patch 3 adds X86_FEATURE_TSXLDTRK.
>>
>> This RFC series has been reviewed by Dave Hansen.
> Yeah, and he and I talked about this on IRC. If you really want to dump
> CPUID to see what's there, we should do a userspace tool in tools/ or
> even use the ones which are already out there: x86info, cpuid, ...
>
> Just adding X86_FEATURE_* flags without usage in the kernel makes no
> sense and will cause unnecessary bloat and doesn't help one bit because
> userspace simply calls CPUID directly.
Could we ignore the new flag patches for the moment and make sure
everyone is on board with what the new Documentation/ says?