xen/25965-x86-ucode-Intel-resume.patch
Charles Arnold 08af757235 - Upstream patches from Jan
25927-x86-domctl-ioport-mapping-range.patch
  25929-tmem-restore-pool-version.patch
  25931-x86-domctl-iomem-mapping-checks.patch
  25940-x86-S3-flush-cache.patch
  25952-x86-MMIO-remap-permissions.patch
  25961-x86-HPET-interrupts.patch
  25962-x86-assign-irq-vector-old.patch
  25965-x86-ucode-Intel-resume.patch

OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=205
2012-10-02 22:08:01 +00:00

36 lines
1.3 KiB
Diff

# HG changeset patch
# User Jan Beulich <jbeulich@suse.com>
# Date 1348817291 -7200
# Node ID 4496d56c68a0e57ed9f03b482028093f1e7fdf6c
# Parent 00c05b9d76247d063a8ebc75050246e488323f50
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>
--- 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 0x%x (current=0x%x)\n",
cpu, mc_header->rev, uci->cpu_sig.rev);