| Message ID | 20241031103401.GBZyNdGQ-ZyXKyzC_z@fat_crate.local (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | x86/cpufeature: Document cpu_feature_enabled() as the default to use | expand |
On 10/31/2024 3:34 AM, Borislav Petkov wrote: > From: "Borislav Petkov (AMD)" <bp@alien8.de> > > cpu_feature_enabled() should be used in most cases when CPU feature > support needs to be tested in code. Document that. > > Reported-by: Sohil Mehta <sohil.mehta@intel.com> > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> > --- > arch/x86/include/asm/cpufeature.h | 18 ++++++------------ > 1 file changed, 6 insertions(+), 12 deletions(-) > Looks good (a minor nit below), Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> > diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h > index 0b9611da6c53..de1ad09fe8d7 100644 > --- a/arch/x86/include/asm/cpufeature.h > +++ b/arch/x86/include/asm/cpufeature.h > @@ -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. > + * Does "default CPU feature testing macro" roll better than "default CPU features testing macro"? > + * 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. > */
On October 31, 2024 7:26:27 PM GMT+01:00, Sohil Mehta <sohil.mehta@intel.com> wrote: >Does "default CPU feature testing macro" roll better than "default CPU >features testing macro"? Waaay too finicky to me. No one cares, I'd say.
On 10/31/24 03:34, Borislav Petkov wrote: > cpu_feature_enabled() should be used in most cases when CPU feature > support needs to be tested in code. Document that. Yes, please. BTW, I know the code generation isn't great in some cases. But this is the right _way_ to call things no "boot_" or &boot_cpu_data for system-wide things. Underlying code generation can continue to be fixed up over time. Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 0b9611da6c53..de1ad09fe8d7 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -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