[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-changelog] [xen-4.2-testing] x86/ucode: fix Intel case of resume handling on boot CPU
# HG changeset patch # User Jan Beulich <jbeulich@xxxxxxxx> # Date 1349338580 -7200 # Node ID a69c8e5c4afcc5a116ec9d3953db425197dc028c # Parent 648c99c230ff3fe75052973251a37ba9c68c6f84 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> Tested-by: Ben Guthro <ben@xxxxxxxxxx> Acked-by: Keir Fraser <keir@xxxxxxx> xen-unstable changeset: 25965:4496d56c68a0 xen-unstable date: Fri Sep 28 07:28:11 UTC 2012 --- diff -r 648c99c230ff -r a69c8e5c4afc xen/arch/x86/microcode_intel.c --- a/xen/arch/x86/microcode_intel.c Thu Oct 04 10:15:16 2012 +0200 +++ b/xen/arch/x86/microcode_intel.c Thu Oct 04 10:16:20 2012 +0200 @@ -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 0x%x (current=0x%x)\n", cpu, mc_header->rev, uci->cpu_sig.rev); _______________________________________________ Xen-changelog mailing list Xen-changelog@xxxxxxxxxxxxx http://lists.xensource.com/xen-changelog
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |