| Message ID | 20230830155326.10199-1-alejandro.vallejo@cloud.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Prevent attempting updates known to fail | expand |
On 30/08/2023 11:53 pm, Alejandro Vallejo wrote: > Now that XENLOG_INFO is the default logging level... > > v8: > * Fixed last bits mentioned by Jan in v7/patch1 (v8/patch2) > * Rolled back to having new printk as INFO > * Added v8/patch1 to ensure the existing early exit from > early_cpu_init() has INFO severity as well. This was posted before we got into RCs. Any view to a release ack? It seems to be in a good state, but I need to double check on affected systems first. Thanks, ~Andrew
Hi Andrew, > On Oct 10, 2023, at 17:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > > On 30/08/2023 11:53 pm, Alejandro Vallejo wrote: >> Now that XENLOG_INFO is the default logging level... >> >> v8: >> * Fixed last bits mentioned by Jan in v7/patch1 (v8/patch2) >> * Rolled back to having new printk as INFO >> * Added v8/patch1 to ensure the existing early exit from >> early_cpu_init() has INFO severity as well. > > This was posted before we got into RCs. Any view to a release ack? I am ok with that, given the status of this series, but you do need to provide a R-b or A-b to the first patch, with that (can be handled on commit): Release-acked-by: Henry Wang <Henry.Wang@arm.com> > > It seems to be in a good state, but I need to double check on affected > systems first. Please do and if possible make sure it will not blow up the CI :) Kind regards, Henry > > Thanks, > > ~Andrew
Now that XENLOG_INFO is the default logging level... v8: * Fixed last bits mentioned by Jan in v7/patch1 (v8/patch2) * Rolled back to having new printk as INFO * Added v8/patch1 to ensure the existing early exit from early_cpu_init() has INFO severity as well. Original cover letter: 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 Modifies the severity of the printk statement in early_microcode_init() to be INFO Patch 2 Ignores microcode facilities when the current microcode revision is -1 (was v7/patch1) Patch 3 Moves the MSR_ARCH_CAPS read in tsx_init() to early_cpu_init() and early_microcode_init() (was v7/patch2) Patch 4 Adds the logic to detect microcode updates being disabled on Intel. (was v7/patch3) Alejandro Vallejo (4): x86/microcode: WARN->INFO for the "no ucode loading" log message 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 | 20 ++++++++++---- xen/arch/x86/cpu/microcode/core.c | 40 +++++++++++++++++++++++---- xen/arch/x86/cpu/microcode/intel.c | 13 +++++++++ xen/arch/x86/cpu/microcode/private.h | 7 +++++ xen/arch/x86/include/asm/cpufeature.h | 1 + xen/arch/x86/include/asm/msr-index.h | 5 ++++ xen/arch/x86/include/asm/setup.h | 2 +- xen/arch/x86/setup.c | 2 +- xen/arch/x86/tsx.c | 16 +++-------- 9 files changed, 82 insertions(+), 24 deletions(-)