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

[Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

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@amd.com>
> 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 #2: xen-hang-latest-tree.jpg --]
[-- Type: image/jpeg, Size: 1660671 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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