[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/2] x86/cpuid: set MCDT_NO for non-affected models
On 13/05/2022 11:35, Roger Pau Monne wrote: > Some CPU models don't exhibit MCDT behavior, but also don't expose > MCDT_NO. Set the MCDT_NO bit for CPUs known to not exhibit the > behavior, so guests can get this information, as using > family/model/stepping detection when running virtualized is not to be > relied. > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> > --- > xen/arch/x86/cpu/intel.c | 70 ++++++++++++++++++++++++++++++++++++++++ > xen/arch/x86/cpuid.c | 10 ++++++ > 2 files changed, 80 insertions(+) > > diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c > index dc6a0c7807..d821f460ae 100644 > --- a/xen/arch/x86/cpu/intel.c > +++ b/xen/arch/x86/cpu/intel.c > @@ -518,6 +518,73 @@ static void intel_log_freq(const struct cpuinfo_x86 *c) > printk("%u MHz\n", (factor * max_ratio + 50) / 100); > } > > +void update_mcdt_no(struct cpuinfo_x86 *c) > +{ > +#define FAM6_MODEL(m, s, c) { 6, m, s, c } > + /* > + * List of models that do not exhibit MCDT behavior, but might not > + * advertise MCDT_NO on CPUID. > + */ > + static const struct { > + uint8_t family; > + uint8_t model; > + uint8_t stepping; > + bool check_stepping; > + } mcdt_no[] = { > + /* Haswell Server EP, EP4S. */ > + FAM6_MODEL(0x3f, 2, true), > + /* Elkhart Lake. */ > + FAM6_MODEL(0x3f, 4, true), > + /* Cherryview. */ > + FAM6_MODEL(0x4c, 0, false), > + /* Broadwell Server E, EP, EP4S, EX. */ > + FAM6_MODEL(0x4f, 0, false), > + /* Broadwell DE V2, V3. */ > + FAM6_MODEL(0x56, 3, true), > + /* Broadwell DE Y0. */ > + FAM6_MODEL(0x56, 4, true), > + /* Broadwell DE A1, Hewitt Lake. */ > + FAM6_MODEL(0x56, 5, true), > + /* Anniedale. */ > + FAM6_MODEL(0x5a, 0, false), > + /* Apollo Lake. */ > + FAM6_MODEL(0x5c, 9, true), > + FAM6_MODEL(0x5c, 0xa, true), > + /* Denverton. */ > + FAM6_MODEL(0x5f, 1, true), > + /* XMM7272. */ > + FAM6_MODEL(0x65, 0, false), > + /* Cougar Mountain. */ > + FAM6_MODEL(0x6e, 0, false), > + /* Butter. */ > + FAM6_MODEL(0x75, 0, false), > + /* Gemini Lake. */ > + FAM6_MODEL(0x7a, 1, true), > + FAM6_MODEL(0x7a, 8, true), > + /* Snowridge. */ > + FAM6_MODEL(0x86, 4, true), > + FAM6_MODEL(0x86, 5, true), > + FAM6_MODEL(0x86, 7, true), > + /* Lakefield B-step. */ > + FAM6_MODEL(0x8a, 1, true), > + /* Elkhart Lake. */ > + FAM6_MODEL(0x96, 1, true), > + /* Jasper Lake. */ > + FAM6_MODEL(0x9c, 0, true), > + { } > + }; > +#undef FAM6_MODEL > + const typeof(mcdt_no[0]) *m; > + > + for (m = mcdt_no; m->family | m->model | m->stepping; m++) > + if ( c->x86 == m->family && c->x86_model == m->model && > + (!m->check_stepping || c->x86_mask == m->stepping) ) > + { > + __set_bit(X86_FEATURE_MCDT_NO, c->x86_capability); > + break; > + } > +} Please could we see about using x86_match_cpu() rather than basically opencoding it? Linux's bug.c has some fairly comprehensive examples of how to do tables like this with it. Also, can we use our shiny new intel-family.h names? The stepping checks guidance seems suspect. Lemme ping some people about that. I suspect that means "we checked the production CPUs but didn't look at the pre-prod hardware" which in practice means we don't care about steppings listed. ~Andrew
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |