All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Jan Beulich" <JBeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH 02/11] x86/ucode/amd: Move check_final_patch_levels() to apply_microcode()
Date: Tue, 31 Mar 2020 11:05:22 +0100	[thread overview]
Message-ID: <20200331100531.4294-3-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <20200331100531.4294-1-andrew.cooper3@citrix.com>

The microcode revision of whichever CPU runs cpu_request_microcode() is not
necessarily applicable to other CPUs.

If the BIOS left us with asymmetric microcode, rejecting updates in
cpu_request_microcode() would prevent us levelling the system even if only up
to the final level.  Also, failing to cache microcode misses an opportunity to
get beyond the final level via the S3 path.

Move check_final_patch_levels() earlier and use it in apply_microcode().
Reword the error message to be more informative, and use -ENXIO as this corner
case has nothing to do with permissions.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/microcode/amd.c | 83 ++++++++++++++++++----------------------
 1 file changed, 38 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index 796745e928..4245dc13bb 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -119,6 +119,36 @@ static bool_t verify_patch_size(uint32_t patch_size)
     return (patch_size <= max_size);
 }
 
+static bool check_final_patch_levels(const struct cpu_signature *sig)
+{
+    /*
+     * 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,
+    };
+    unsigned int i;
+
+    if ( boot_cpu_data.x86 != 0x10 )
+        return false;
+
+    for ( i = 0; i < ARRAY_SIZE(final_levels); i++ )
+        if ( sig->rev == final_levels[i] )
+            return true;
+
+    return false;
+}
+
 static bool_t find_equiv_cpu_id(const struct equiv_cpu_entry *equiv_cpu_table,
                                 unsigned int current_cpu_id,
                                 unsigned int *equiv_cpu_id)
@@ -229,6 +259,14 @@ static int apply_microcode(const struct microcode_patch *patch)
     if ( !match_cpu(patch) )
         return -EINVAL;
 
+    if ( check_final_patch_levels(sig) )
+    {
+        printk(XENLOG_ERR
+               "microcode: CPU%u current rev %#x unsafe to update\n",
+               cpu, sig->rev);
+        return -ENXIO;
+    }
+
     hdr = patch->mpb;
 
     hw_err = wrmsr_safe(MSR_AMD_PATCHLOADER, (unsigned long)hdr);
@@ -374,43 +412,6 @@ static int container_fast_forward(const void *data, size_t size_left, size_t *of
     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.
-     */
-    const struct cpu_signature *sig = &per_cpu(cpu_sig, cpu);
-    unsigned int i;
-
-    if ( boot_cpu_data.x86 != 0x10 )
-        return 0;
-
-    for ( i = 0; i < ARRAY_SIZE(final_levels); i++ )
-        if ( sig->rev == final_levels[i] )
-            return 1;
-
-    return 0;
-}
-
 static struct microcode_patch *cpu_request_microcode(const void *buf,
                                                      size_t bufsize)
 {
@@ -434,14 +435,6 @@ static struct microcode_patch *cpu_request_microcode(const void *buf,
         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 = xzalloc(struct microcode_amd);
     if ( !mc_amd )
     {
-- 
2.11.0



  parent reply	other threads:[~2020-03-31 10:06 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 10:05 [PATCH 00/11] x86/ucode: Cleanup and fixes - Part 4/n (AMD) Andrew Cooper
2020-03-31 10:05 ` [PATCH 01/11] x86/ucode/amd: Fix more potential buffer overruns with microcode parsing Andrew Cooper
2020-03-31 10:05 ` Andrew Cooper [this message]
2020-03-31 14:27   ` [PATCH 02/11] x86/ucode/amd: Move check_final_patch_levels() to apply_microcode() Jan Beulich
2020-03-31 10:05 ` [PATCH 03/11] x86/ucode/amd: Don't use void * for microcode_patch->mpb Andrew Cooper
2020-03-31 14:28   ` Jan Beulich
2020-03-31 10:05 ` [PATCH 04/11] x86/ucode/amd: Collect CPUID.1.EAX in collect_cpu_info() Andrew Cooper
2020-03-31 14:29   ` Jan Beulich
2020-03-31 10:05 ` [PATCH 05/11] x86/ucode/amd: Overhaul the equivalent cpu table handling completely Andrew Cooper
2020-03-31 14:36   ` Jan Beulich
2020-03-31 10:05 ` [PATCH 06/11] x86/ucode/amd: Move verify_patch_size() into get_ucode_from_buffer_amd() Andrew Cooper
2020-03-31 14:38   ` Jan Beulich
2020-03-31 10:05 ` [PATCH 07/11] x86/ucode/amd: Alter API for microcode_fits() Andrew Cooper
2020-03-31 14:39   ` Jan Beulich
2020-03-31 10:05 ` [PATCH 08/11] x86/ucode/amd: Rename bufsize to size in cpu_request_microcode() Andrew Cooper
2020-03-31 14:41   ` Jan Beulich
2020-03-31 14:43     ` Andrew Cooper
2020-03-31 10:05 ` [PATCH 09/11] x86/ucode/amd: Remove gratuitous memory allocations from cpu_request_microcode() Andrew Cooper
2020-03-31 14:51   ` Jan Beulich
2020-03-31 14:55     ` Andrew Cooper
2020-03-31 15:13       ` Jan Beulich
2020-03-31 15:47         ` Andrew Cooper
2020-03-31 15:52           ` Jan Beulich
2020-03-31 10:05 ` [PATCH 10/11] x86/ucode/amd: Fold structures together Andrew Cooper
2020-03-31 14:53   ` Jan Beulich
2020-03-31 10:05 ` [PATCH 11/11] x86/ucode/amd: Rework parsing logic in cpu_request_microcode() Andrew Cooper
2020-03-31 15:07   ` Jan Beulich
2020-03-31 15:19     ` Andrew Cooper
2020-03-31 15:27       ` Jan Beulich
2020-03-31 15:55         ` Andrew Cooper
2020-03-31 16:00           ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200331100531.4294-3-andrew.cooper3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.