[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b6cc9c0-491f-689f-b7e9-e2c7a32182aa@intel.com>
Date: Thu, 11 Jun 2020 07:05:08 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Borislav Petkov <bp@...en8.de>,
Kyung Min Park <kyung.min.park@...el.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, tglx@...utronix.de,
mingo@...hat.com, hpa@...or.com, gregkh@...uxfoundation.org,
ak@...ux.intel.com, tony.luck@...el.com, ravi.v.shankar@...el.com,
ricardo.neri@...el.com
Subject: Re: [RFC PATCH 0/3] Add Documentation for /proc/cpuinfo flags
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?
Powered by blists - more mailing lists