[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/3] x86: check feature flags after resume
Simon Gaiser: > Jan Beulich: >> Make sure no previously present features are missing after resume (and >> the re-loading of microcode), to avoid later crashes or (likely silent) >> hangs / live locks. This doesn't go beyond checking x86_capability[], >> but this should be good enough for the immediate need of making sure >> that the BIT mitigation MSRs are still available. >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >> >> --- a/xen/arch/x86/acpi/power.c >> +++ b/xen/arch/x86/acpi/power.c >> @@ -254,6 +254,9 @@ static int enter_state(u32 state) >> >> microcode_resume_cpu(0); >> >> + if ( !recheck_cpu_features(0) ) >> + panic("Missing previously available feature(s)."); >> + >> ci->bti_ist_info = default_bti_ist_info; >> asm volatile (ALTERNATIVE("", "wrmsr", X86_FEATURE_XEN_IBRS_SET) >> :: "a" (SPEC_CTRL_IBRS), "c" (MSR_SPEC_CTRL), "d" (0) >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -501,6 +501,9 @@ void identify_cpu(struct cpuinfo_x86 *c) >> printk("\n"); >> #endif >> >> + if (system_state == SYS_STATE_resume) >> + return; >> + >> /* >> * On SMP, boot_cpu_data holds the common feature set between >> * all CPUs; so make sure that we indicate which features are >> --- a/xen/arch/x86/cpuid.c >> +++ b/xen/arch/x86/cpuid.c >> @@ -473,6 +473,28 @@ void __init init_guest_cpuid(void) >> calculate_hvm_max_policy(); >> } >> >> +bool recheck_cpu_features(unsigned int cpu) >> +{ >> + bool okay = true; >> + struct cpuinfo_x86 c; >> + const struct cpuinfo_x86 *bsp = &boot_cpu_data; >> + unsigned int i; >> + >> + identify_cpu(&c); > > This runs into a bug in identify_cpu(). x86_vendor_id does not get > zeroed, so the x86_vendor_id is not null terminated and the vendor > identification fails. > > diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c > index 4feaa2ceb6..5750d26216 100644 > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -366,8 +366,8 @@ void identify_cpu(struct cpuinfo_x86 *c) > c->x86_vendor = X86_VENDOR_UNKNOWN; > c->cpuid_level = -1; /* CPUID not detected */ > c->x86_model = c->x86_mask = 0; /* So far unknown... */ > - c->x86_vendor_id[0] = '\0'; /* Unset */ > - c->x86_model_id[0] = '\0'; /* Unset */ > + memset(&c->x86_vendor_id, 0, sizeof(c->x86_vendor_id)); > + memset(&c->x86_model_id, 0, sizeof(c->x86_model_id)); > c->x86_max_cores = 1; > c->x86_num_siblings = 1; > c->x86_clflush_size = 0; > > With this patch it works for me. Meh, also a backport failure from me. Since e34bc403c3c7 this problem should not appear since it does not assume a null terminated string. Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |