aboutsummaryrefslogtreecommitdiffstats
path: root/xen/arch/x86/microcode_intel.c
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2012-09-28 09:28:11 +0200
committerJan Beulich <jbeulich@suse.com>2012-09-28 09:28:11 +0200
commit0e82871ca3222f91ffe8b96768ece1b89ce96d12 (patch)
tree64929f5c6a36e50efc8e79ce5c14e0eff6273cd6 /xen/arch/x86/microcode_intel.c
parent24c152c7fec0cf0d788500482cfed09c4a0c527d (diff)
downloadxen-0e82871ca3222f91ffe8b96768ece1b89ce96d12.tar.gz
xen-0e82871ca3222f91ffe8b96768ece1b89ce96d12.tar.bz2
xen-0e82871ca3222f91ffe8b96768ece1b89ce96d12.zip
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@suse.com> Tested-by: Ben Guthro <ben@guthro.net> Acked-by: Keir Fraser <keir@xen.org>
Diffstat (limited to 'xen/arch/x86/microcode_intel.c')
-rw-r--r--xen/arch/x86/microcode_intel.c2
1 files changed, 0 insertions, 2 deletions
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index afaf61f4c5..b54cd714ab 100644
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -261,8 +261,6 @@ static int get_matching_microcode(const void *mc, int cpu)
}
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);