Some hypervisors report ~0 as the microcode revision to mean "don't issue microcode updates". Ignore the microcode loading interface in that case.
Signed-off-by: Alejandro Vallejo <alejandro.vall...@cloud.com> Reviewed-by: Jan Beulich <jbeul...@suse.com> --- v6: * Change message content and move severity WARNING -> INFO (Andrew) NOTE: It has a convoluted argument to simplify the last patch, that uses the same printk() --- xen/arch/x86/cpu/microcode/core.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index bec8b55db2..71e3944cf2 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -867,10 +867,23 @@ int __init early_microcode_init(unsigned long *module_map, return -ENODEV; } - microcode_grab_module(module_map, mbi); - ucode_ops.collect_cpu_info(); + /* + * Some hypervisors deliberately report a microcode revision of -1 to + * mean that they will not accept microcode updates. We take the hint + * and ignore the microcode interface in that case. + */ + if ( this_cpu(cpu_sig).rev == ~0 ) + { + printk(XENLOG_INFO "Microcode loading disabled due to: %s", + "HW toggle"); + ucode_ops.apply_microcode = NULL; + return -ENODEV; + } + + microcode_grab_module(module_map, mbi); + if ( ucode_mod.mod_end || ucode_blob.size ) rc = early_microcode_update_cpu(); -- 2.34.1