[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen4.2 S3 regression?
>>> On 27.09.12 at 14:12, Ben Guthro <ben@xxxxxxxxxx> wrote: > On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >> > (XEN) microcode: collect_cpu_info for CPU0 >> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c >> > (XEN) microcode: collect_cpu_info for CPU1 >> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f >> >> And in the end we see that both cores run on different revisions. >> >> > very interesting. I had overlooked that. Could you give the below patch a try? Jan x86/ucode: fix Intel case of resume handling on boot CPU Checking the stored version doesn't tell us anything about the need to apply the update (during resume, what is stored doesn't necessarily match what is loaded). Note that the check can be removed altogether because once switched to use what was read from the CPU (uci->cpu_sig.rev, as used in the subsequent pr_debug()), it would become redundant with the checks that lead to microcode_update_match() returning the indication that an update should be applied. Note further that this was not an issue on APs since they start with uci->mc.mc_intel being NULL. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> --- a/xen/arch/x86/microcode_intel.c +++ b/xen/arch/x86/microcode_intel.c @@ -261,8 +261,6 @@ static int get_matching_microcode(const } return 0; find: - if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev ) - return 0; pr_debug("microcode: CPU%d found a matching microcode update with" " version %#x (current=%#x)\n", cpu, mc_header->rev, uci->cpu_sig.rev); _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |