[PATCH v2 0/5] Prevent attempting updates known to fail

Alejandro Vallejo posted 5 patches 10 months, 2 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20230615154834.959-1-alejandro.vallejo@cloud.com
There is a newer version of this series
xen/arch/x86/cpu/common.c             |  5 ++++
xen/arch/x86/cpu/microcode/amd.c      | 16 +++++++----
xen/arch/x86/cpu/microcode/core.c     | 41 ++++++++++++++++++++-------
xen/arch/x86/cpu/microcode/intel.c    | 27 ++++++++++++++----
xen/arch/x86/cpu/microcode/private.h  | 19 ++++++++++++-
xen/arch/x86/include/asm/cpufeature.h |  1 +
xen/arch/x86/include/asm/msr-index.h  |  5 ++++
xen/arch/x86/tsx.c                    | 15 ++--------
8 files changed, 93 insertions(+), 36 deletions(-)
[PATCH v2 0/5] Prevent attempting updates known to fail
Posted by Alejandro Vallejo 10 months, 2 weeks ago
v3:
  * Lots of hunks moved around. Individually mentioned in each patch
  * Removed a redundant check
  * Ignore microcode interface if the revision is -1
  * Perform the DIS_MCU_LOAD checks during init rather than apply time


Under certain conditions a CPU may not be able to perform microcode updates
even if hardware exists to that effect. In particular:

 * If Xen runs under certain hypervisors they won't allow microcode
   updates, and will signal this fact by reporting a microcode revision of
   -1.
 * If the DIS_MCU_LOAD bit is set, which is expected in some baremetal
   clouds where the owner may not trust the tenant, then the CPU is not
   capable of loading new microcode.

This series adds logic so that in both of these cases we don't needlessly
attempt updates that are not going to succeed. Patch summary:

Patch 1 Does the refactors to allow collecting cpu info on systems with
        microcode updates disabled

Patch 2 Isolates early_microcode_init() per-vendor logic in per-vendor
        functions

Patch 3 Recognizes microcode revision of -1 as a hint meaning "don't use the
        microcode interface".

Patch 4 Moves the MSR_ARCH_CAPS read from tsx_init() to
        early_microcode_init()

Patch 5 Adds the logic to detect microcode updates being disabled on Intel.

Alejandro Vallejo (5):
  x86/microcode: Allow reading microcode revision even if it can't be
    updated
  x86/microcode: Create per-vendor microcode_ops builders
  x86/microcode: Ignore microcode loading interface for revision = -1
  x86: Read MSR_ARCH_CAPS immediately after early_microcode_init()
  x86/microcode: Disable microcode update handler if DIS_MCU_UPDATE is
    set

 xen/arch/x86/cpu/common.c             |  5 ++++
 xen/arch/x86/cpu/microcode/amd.c      | 16 +++++++----
 xen/arch/x86/cpu/microcode/core.c     | 41 ++++++++++++++++++++-------
 xen/arch/x86/cpu/microcode/intel.c    | 27 ++++++++++++++----
 xen/arch/x86/cpu/microcode/private.h  | 19 ++++++++++++-
 xen/arch/x86/include/asm/cpufeature.h |  1 +
 xen/arch/x86/include/asm/msr-index.h  |  5 ++++
 xen/arch/x86/tsx.c                    | 15 ++--------
 8 files changed, 93 insertions(+), 36 deletions(-)

-- 
2.34.1
Re: [PATCH v2 0/5] Prevent attempting updates known to fail
Posted by Alejandro Vallejo 10 months, 2 weeks ago
On Thu, Jun 15, 2023 at 04:48:29PM +0100, Alejandro Vallejo wrote:
> v3:
>   * Lots of hunks moved around. Individually mentioned in each patch
>   * Removed a redundant check
>   * Ignore microcode interface if the revision is -1
>   * Perform the DIS_MCU_LOAD checks during init rather than apply time

You might think that looks a whole lot like the enumeration in v2, and
you'd be right :) . I sent this ahead of time and that's incorrect. The
actual summary is:

  * Lots of hunks moved around. Individually mentioned in each patch
  * MSR_ARCH_CAPS read in early_cpu_init()
  * Per-vendor functions used to encapsulate vendor-specific logic in
    early_microcode_init()
  * Inlined previous helper for realoading 7d0

It addresses most concerns raised, but the final look is a bit different
from what was reviewed before. I think it's a lot cleaner and allows future
per-vendor logic to be neatly integrated into their per-vendor files.

Alejandro