On Tue, 2018-01-23 at 17:28 -0800, Dave Hansen wrote: > On 01/23/2018 05:23 PM, Woodhouse, David wrote: > > > > On Tue, 2018-01-23 at 10:43 -0800, Dave Hansen wrote: > ... > > > > > > > > > > > > > /* 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 */ > > > > +#define X86_FEATURE_SPEC_CTRL (18*32+26) /* Speculation > > > > Control (IBRS + IBPB) */ > > > > +#define X86_FEATURE_STIBP (18*32+27) /* Single Thread > > > > Indirect Branch Predictors */ > > > > +#define X86_FEATURE_ARCH_CAPABILITIES (18*32+29) /* > > > > IA32_ARCH_CAPABILITIES MSR (Intel) */ > > > Should we be adding flags (STIBP) for which we currently have no user in > > > the kernel? > > They're in an existing word (now) so it costs us absolutely nothing to > > do so. And they'll be exposed to KVM guests in imminent patches if > > nothing else. > > Doesn't just defining it here generate something in the tables that then > get exported in /proc/cpuinfo? That's far from our most strict ABI, but > a single #define here can be seen by users IIRC.
That's true, but still we're *working* on exposing and using these; let's not go wild adding one feature at a time and having to tweak the surrounding blacklist/enable/disable/expose logic at every step.
smime.p7s
Description: S/MIME cryptographic signature
