[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86, amd_ucode: Safeguard against #GP



On 5/21/2014 5:08 PM, Andrew Cooper wrote:
On 21/05/2014 22:28, Aravind Gopalakrishnan wrote:
When HW tries to load a corrupted patch, it generates #GP
and hangs the system. Use wrmsr_safe instead so that we
fail to load microcode gracefully.

Example on a Fam15h system-
(XEN) microcode: CPU0 collect_cpu_info: patch_id=0x6000626
(XEN) microcode: CPU0 size 7870, block size 2586 offset 76 equivID
0x6012 rev 0x6000637
(XEN) microcode: CPU0 found a matching microcode update with version
0x6000637 (current=0x6000626)
(XEN) traps.c:3073: GPF (0000): ffff82d08016f682 -> ffff82d08022d9f8
(XEN) microcode: CPU0 update from revision 0x6000637 to 0x6000626 failed

Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
I suspect that you will find with a *very* up-to-date master tree, an
early #GP should result in panic() instead of a hang, following
279840d5ea646  (If it doesn't I would be interested to know)

The console log states 'Panic on CPU0'. But system is basically hung after that.
(attached snapshot)
As for the patch itself, is it worth using the failure to purge this
patch from the cache? Nothing good can come of attempting to load the
same patch on a different cpu.



I don't think we do..
We only save the patch for apply on resume if 'applied_offset' has a value right?

-Aravind.

Attachment: xen-hang-latest-tree.jpg
Description: JPEG image

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.