I know that Vmware hypervisors at least have a setting to ignore CPU microcode updates from within the guest OS (no surprise).
CPU microcode update available. The guest OS tried to update the microcode from patch level XX (YYh) to patch level ZZ (TTh), but VMware ESX does not allow microcode patches to be applied from within a virtual machine. Microcode patches are used to correct CPU errata. If you are not experiencing any problems with your CPU, you can ignore this microcode patch. Otherwise, you may be able to obtain a BIOS/firmware update which includes this microcode patch from your system vendor, or your host OS may provide a facility for loading microcode patches obtained directly from the Intel web site.
Is this the case with all hypervisors (like KVM, where a Virtual Qemu CPU gets presented) or is there maybe a setting for Vmware Vsphere where the detected microcode update from the guest machine gets staged to be used by the hypervisors microcode loading mechanism (e.g. when the microcode is authentic and the version is newer than the installed microcode)?
No guest machine may ever upload microcode to the hypervisor's CPU except when the microcode is specific for a virtualized CPU. But then again, what use would it have? The hypervisor's code could also be updated to just change the virtual CPU.
Spectre needs to be mitigated on Hypervisor level and thus needs proper Bios firmware and/or microcode uploads by the Hypervisor. Microcode cannot be fixed via the guest os.
Red Hat withdrawed microcode updates related to Spectre and virtual machines try to upload microcode during boot.
Mon Jan 15 2018 Petr Oros - 1:1.17-25.4 Use right upstream source for revert Resolves: #1533978
Fri Jan 12 2018 Petr Oros - 1:1.17-25.3 Revert Microcode from Intel and AMD for Side Channel attack Resolves: #1533978
Changelog of the microcode_ctl RPM