linux-kernel - Re: [tip:x86/urgent] x86/cpufeature: Add AVX512_4VNNIW and AVX512

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <A31EBDF6-87E7-4857-9E93-CD471BA7C5C0@zytor.com>
Date:   Sun, 16 Oct 2016 09:02:51 -0700
From:   hpa@...or.com
To:     Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>,
        peterz@...radead.org, tglx@...utronix.de, dave.hansen@...el.com,
        torvalds@...ux-foundation.org, piotr.luc@...el.com,
        luto@...nel.org, brgerst@...il.com, linux-kernel@...r.kernel.org,
        dvlasenk@...hat.com, jpoimboe@...hat.com
CC:     linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

On October 16, 2016 7:22:33 AM PDT, Borislav Petkov <bp@...en8.de> wrote:
>On Sun, Oct 16, 2016 at 04:21:49AM -0700, tip-bot for Piotr Luc wrote:
>> Commit-ID:  a518dcc82b6162009c8ca3d169fe61c81536ff17
>> Gitweb:    
>http://git.kernel.org/tip/a518dcc82b6162009c8ca3d169fe61c81536ff17
>> Author:     Piotr Luc <piotr.luc@...el.com>
>> AuthorDate: Wed, 12 Oct 2016 19:57:31 +0200
>> Committer:  Ingo Molnar <mingo@...nel.org>
>> CommitDate: Sun, 16 Oct 2016 11:32:11 +0200
>> 
>> x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features
>> 
>> AVX512_4VNNIW  - Vector instructions for deep learning enhanced word
>> variable precision.
>> AVX512_4FMAPS - Vector instructions for deep learning floating-point
>> single precision.
>> 
>> The new instructions are to be used in future Intel Xeon & Xeon Phi
>> processors.
>> 
>> The spec can be found in Intel Software Developer Manual or in
>> Instruction Set Extensions Programming Reference. See
>>
>https://software.intel.com/sites/default/files/managed/69/78/319433-025.pdf.
>> 
>> Signed-off-by: Piotr Luc <piotr.luc@...el.com>
>> Reviewed-by: Dave Hansen <dave.hansen@...el.com>
>> Cc: Andy Lutomirski <luto@...nel.org>
>> Cc: Borislav Petkov <bp@...en8.de>
>> Cc: Brian Gerst <brgerst@...il.com>
>> Cc: Denys Vlasenko <dvlasenk@...hat.com>
>> Cc: H. Peter Anvin <hpa@...or.com>
>> Cc: Josh Poimboeuf <jpoimboe@...hat.com>
>> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>> Cc: Peter Zijlstra <peterz@...radead.org>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Link:
>http://lkml.kernel.org/r/20161012175731.29619-1-piotr.luc@intel.com
>> Signed-off-by: Ingo Molnar <mingo@...nel.org>
>
>...
>
>> diff --git a/arch/x86/include/asm/cpufeatures.h
>b/arch/x86/include/asm/cpufeatures.h
>> index 1188bc8..6697b75 100644
>> --- a/arch/x86/include/asm/cpufeatures.h
>> +++ b/arch/x86/include/asm/cpufeatures.h
>> @@ -12,7 +12,7 @@
>>  /*
>>   * Defines x86 CPU feature bits
>>   */
>> -#define NCAPINTS	18	/* N 32-bit words worth of info */
>> +#define NCAPINTS	19	/* N 32-bit words worth of info */
>>  #define NBUGINTS	1	/* N 32-bit bug flags */
>>  
>>  /*
>> @@ -285,6 +285,10 @@
>>  #define X86_FEATURE_SUCCOR	(17*32+1) /* Uncorrectable error
>containment and recovery */
>>  #define X86_FEATURE_SMCA	(17*32+3) /* Scalable MCA */
>>  
>> +/* Intel-defined CPU features, CPUID level 0x00000007:0 (edx), word
>18 */
>> +#define X86_FEATURE_AVX512_4VNNIW  (18*32+2) /* AVX-512 Neural
>Network Instructions */
>> +#define X86_FEATURE_AVX512_4FMAPS  (18*32+3) /* AVX-512 Multiply
>Accumulation Single precision */
>
>This is getting ridiculous: we keep adding new leafs to
>->x86_capability, thus bloating cpuinfo_x86 but then it is not even
>worth it - this patch defines only two bits.
>
>I know, I know, it is a CPUID leaf of features, we will need them,
>yadda
>yadda but until we do, I'd suggest these all new feature bits to to
>init_scattered_cpuid_features() and be carved out to a leaf of their
>own *only* when we really, actually add them and fill up that leaf.
>Otherwise, we have one fat and sparse x86_capability array.

No, please.  That would be worse than the disease.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.