On Sat, Jan 27, 2018 at 09:27:48AM +0000, David Woodhouse wrote:
> http://david.woodhou.se/cleanup-feature-bits.patch on top of my full
> tree?
@@ -223,7 +223,7 @@ static inline void indirect_branch_prediction_barrier(void)
"movl %[val], %%eax\n\t"
"movl $0, %%edx\n\t"
"wrmsr",
- X86_FEATURE_IBPB)
+ X86_FEATURE_USE_IBPB)
I still don't think that's the right approach: I'd call the
software-defined, synthetic features
X86_FEATURE_IBPB
X86_FEATURE_IBRS
X86_FEATURE_STIBP
then make *them* visible in /proc/cpuinfo and use them everywhere in the
code.
Only the vendor-specific detection code will set the synthetic ones when
it detects a corresponding vendor-specific one.
This way one *only* concentrates on the three above everywhere and
only low-level, early, vendor-specific code takes care to set the
corresponding synthetic features based on the actual hardware bits it
detects.
I think that unifies the view both to the user *and* to the rest of the
kernel which should not care about the actual name of a hardware feature
bit.
And then you avoid coders scratching heads, asking, so what should I
use, X86_FEATURE_IBPB or X86_FEATURE_USE_IBPB.
Instead you call IBPB the synthetic one and the hardware feature name is
something different like PRED_CMD or so. This will drop the confusion
additionally.
I hope that makes sense.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|