Re: [PATCH 3/4] v6 more sampling fun 3
Thomas Gleixner <[email protected]> Fri, 10 Apr 2020 00:36:09 +0200
| Newsgroups | org.kernel.lore.historical-speck |
|---|---|
| Message-ID | <[email protected]> |
Mark, speck for mark gross <[email protected]> writes: > +#define VULNBL_INTEL_STEPPING(model, steppings, issues) \ > + X86_MATCH_VENDOR_FAM_MODEL_STEPPING_FEATURE(INTEL, 6, \ > + INTEL_FAM6_##model, steppings, \ > + X86_FEATURE_ANY, issues) > + > +#define SRBDS BIT(0) > + > +static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { > + VULNBL_INTEL_STEPPING(IVYBRIDGE, X86_STEPPING_ANY, SRBDS), > + VULNBL_INTEL_STEPPING(HASWELL, X86_STEPPING_ANY, SRBDS), > + VULNBL_INTEL_STEPPING(HASWELL_L, X86_STEPPING_ANY, SRBDS), > + VULNBL_INTEL_STEPPING(HASWELL_G, X86_STEPPING_ANY, SRBDS), > + VULNBL_INTEL_STEPPING(BROADWELL_G, X86_STEPPING_ANY, SRBDS), > + VULNBL_INTEL_STEPPING(BROADWELL, X86_STEPPING_ANY, SRBDS), > + VULNBL_INTEL_STEPPING(SKYLAKE_L, X86_STEPPING_ANY, SRBDS), > + VULNBL_INTEL_STEPPING(SKYLAKE, X86_STEPPING_ANY, SRBDS), > + VULNBL_INTEL_STEPPING(KABYLAKE_L, GENMASK(0xC, 0), SRBDS), /*06_8E steppings <=C*/ > + VULNBL_INTEL_STEPPING(KABYLAKE, GENMASK(0xD, 0), SRBDS), /*06_9E steppings <=D*/ Please don't use these horrible tail comments. Also the 06_NN part is of that comment is not helpful either. Please make stuff self explaining, i.e. #define X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins) and use that in the blacklist: VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0, 0xC), SRBDS), VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0, 0xD), SRBDS), which is pretty obvious, right? > static bool __init cpu_matches(unsigned long which, const struct x86_cpu_id *table) > { > const struct x86_cpu_id *m = x86_match_cpu(table); > @@ -1142,6 +1163,27 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) > (ia32_cap & ARCH_CAP_TSX_CTRL_MSR))) > setup_force_cpu_bug(X86_BUG_TAA); > > + if (cpu_matches(SRBDS, cpu_vuln_blacklist)) { > + /* > + * Some parts on the list don't have RDRAND or RDSEED. Make sure > + * they show as "Not affected". > + */ > + if (!cpu_has(c, X86_FEATURE_RDRAND) && > + !cpu_has(c, X86_FEATURE_RDSEED)) > + goto srbds_not_affected; > + /* > + * Parts that have TSX fused off and are not affected by MDS > + * are not affected by SRBDS. TSX_CTRL is only enumerated on > + * parts where TSX fused on. > + */ > + if ((ia32_cap & ARCH_CAP_MDS_NO) && > + !(ia32_cap & ARCH_CAP_TSX_CTRL_MSR)) > + goto srbds_not_affected; This is confusing vs. the documentation patch: >+ Kabylake_L 06_8EH 0xB only if TSX is enabled >+ Kabylake_L 06_8EH 0xC only if TSX is enabled >+ >+ Kabylake 06_9EH <=B >+ Kabylake 06_9EH 0xC only if TSX is enabled >+ Kabylake 06_9EH 0xD only if TSX is enabled IOW, this is only true for particular steppings of Kabylake[_L] It might well be the case that exactly these steppings have MDS_NO and might have TSX fused off, but can we pretty please make this very explicit? VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0x0, 0xA), SRBDS), VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0xB, 0xC), SRBDS_IF_TSX), VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0x0, 0xB), SRBDS), VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0xC, 0xD), SRBDS_IF_TSX), and make the check for SRBDS_IF_TSX & TSX enabled in the code? You surely figure out how to define SRBDS_IF_TSX so the SRBDS match works for both :) Thanks, tglx