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
