| Message ID | 20230615154834.959-1-alejandro.vallejo@cloud.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Prevent attempting updates known to fail | expand |
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
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(-)