[Xen-changelog] [xen stable-4.4] x86, amd_ucode: skip microcode updates for final levels

[patchbot@xxxxxxx]

commit 6657f1b596c046c676d280ae6d57ae59de17804e
Author:     Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
AuthorDate: Thu Sep 10 15:51:02 2015 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Thu Sep 10 15:51:02 2015 +0200

    x86, amd_ucode: skip microcode updates for final levels
    
    Some of older[Fam10h] systems require that certain number of
    applied microcode patch levels should not be overwritten by
    the microcode loader. Otherwise, system hangs are known to occur.
    
    The 'final_levels' of patch ids have been obtained empirically.
    Refer bug https://bugzilla.suse.com/show_bug.cgi?id=913996
    for details of the issue.
    
    The short version is that people have predominantly noticed
    system hang issues when trying to update microcode levels
    beyond the patch IDs below.
    [0x01000098, 0x0100009f, 0x010000af]
    
    From internal discussions, we gathered that OS/hypervisor
    cannot reliably perform microcode updates beyond these levels
    due to hardware issues. Therefore, we need to abort microcode
    update process if we hit any of these levels.
    
    In this patch, we check for those microcode versions and abort
    if the current core has one of those final patch levels applied
    by the BIOS
    
    A linux version of the patch has already made it into tip-
    http://marc.info/?l=linux-kernel&m=143703405627170
    
    Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    master commit: 22c5675877c8209adcfdb6bceddb561320374529
    master date: 2015-08-25 16:17:13 +0200
---
 xen/arch/x86/microcode_amd.c |   45 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
index 32d7fa1..ed7f7ea 100644
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -270,6 +270,43 @@ static int install_equiv_cpu_table(
     return 0;
 }
 
+/*
+ * The 'final_levels' of patch ids have been obtained empirically.
+ * Refer bug https://bugzilla.suse.com/show_bug.cgi?id=913996
+ * for details of the issue. The short version is that people
+ * using certain Fam10h systems noticed system hang issues when
+ * trying to update microcode levels beyond the patch IDs below.
+ * From internal discussions, we gathered that OS/hypervisor
+ * cannot reliably perform microcode updates beyond these levels
+ * due to hardware issues. Therefore, we need to abort microcode
+ * update process if we hit any of these levels.
+ */
+static const unsigned int final_levels[] = {
+    0x01000098,
+    0x0100009f,
+    0x010000af
+};
+
+static bool_t check_final_patch_levels(unsigned int cpu)
+{
+    /*
+     * Check the current patch levels on the cpu. If they are equal to
+     * any of the 'final_levels', then we should not update the microcode
+     * patch on the cpu as system will hang otherwise.
+     */
+    struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
+    unsigned int i;
+
+    if ( boot_cpu_data.x86 != 0x10 )
+        return 0;
+
+    for ( i = 0; i < ARRAY_SIZE(final_levels); i++ )
+        if ( uci->cpu_sig.rev == final_levels[i] )
+            return 1;
+
+    return 0;
+}
+
 static int cpu_request_microcode(int cpu, const void *buf, size_t bufsize)
 {
     struct microcode_amd *mc_amd, *mc_old;
@@ -288,6 +325,14 @@ static int cpu_request_microcode(int cpu, const void *buf, 
size_t bufsize)
         goto out;
     }
 
+    if ( check_final_patch_levels(cpu) )
+    {
+        printk(XENLOG_INFO
+               "microcode: Cannot update microcode patch on the cpu as we hit 
a final level\n");
+        error = -EPERM;
+        goto out;
+    }
+
     mc_amd = xmalloc(struct microcode_amd);
     if ( !mc_amd )
     {
--
generated by git-patchbot for /home/xen/git/xen.git#stable-4.4

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog