Commit 4bf61049 authored by Borislav Petkov (AMD)'s avatar Borislav Petkov (AMD)
Browse files

x86/cpufeature: Document cpu_feature_enabled() as the default to use 



cpu_feature_enabled() should be used in most cases when CPU feature
support needs to be tested in code. Document that.

Reported-by: default avatarSohil Mehta <sohil.mehta@intel.com>
Signed-off-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: default avatarSohil Mehta <sohil.mehta@intel.com>
Acked-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/r/20241031103401.GBZyNdGQ-ZyXKyzC_z@fat_crate.local
parent 29188c16

arch/x86/include/asm/cpufeature.h

+6 −12
Original line number Diff line number Diff line
@@ -132,11 +132,12 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; 
	 x86_this_cpu_test_bit(bit, cpu_info.x86_capability))



/*

 * This macro is for detection of features which need kernel

 * infrastructure to be used.  It may *not* directly test the CPU

 * itself.  Use the cpu_has() family if you want true runtime

 * testing of CPU features, like in hypervisor code where you are

 * supporting a possible guest feature where host support for it

 * This is the default CPU features testing macro to use in code.

 *

 * It is for detection of features which need kernel infrastructure to be

 * used.  It may *not* directly test the CPU itself.  Use the cpu_has() family

 * if you want true runtime testing of CPU features, like in hypervisor code

 * where you are supporting a possible guest feature where host support for it

 * is not relevant.

 */

#define cpu_feature_enabled(bit)	\
@@ -161,13 +162,6 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); 
#define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)



/*

 * Static testing of CPU features. Used the same as boot_cpu_has(). It

 * statically patches the target code for additional performance. Use

 * static_cpu_has() only in fast paths, where every cycle counts. Which

 * means that the boot_cpu_has() variant is already fast enough for the

 * majority of cases and you should stick to using it as it is generally

 * only two instructions: a RIP-relative MOV and a TEST.

 *

 * Do not use an "m" constraint for [cap_byte] here: gcc doesn't know

 * that this is only used on a fallback path and will sometimes cause

 * it to manifest the address of boot_cpu_data in a register, fouling