On linux you can enable an option in the kernel to update microcode at runtime (late microcode loading), but this is not recommended as you have processes that started before the late microcode update and thus might have already ran into cpu bugs

> might have already ran into cpu bugs

Not only that. There were microcode updates which disabled CPU features (most notably TSX). During process startup such features might have been detected as available and decided to use optimized subroutines. Disabling features while the process is still running might either severely degrade performance or outright crash it.

Was TSX ever used? I didn't even see an ounce of dev documentation about it.

HLE, which is a subset of TSX, is (was?) supported by glibc [1]. Not sure if it is enabled by default. If it is, pretty much every multithreaded linux process would be affected.

[1] https://www.gnu.org/software/libc/manual/html_node/Elision-T...

And, more presently relevant, the actual sequence of CPU state manipulations needed to apply the update reliably in gnarly. Hopefully the thing currently implemented in Linux is fully reliable.

I think you can load microcode after boot, it's just more likely to have weird effects, especially with older processors.

For VMs running in GCP, they do migrate VMs across machines from time to time, and you could handwave a process where they take a machkne, update the hypervisor image with new microcode, migrate all VMs off the machine, then make it available to receive VM migrations. Migrating a VM is disruptive, although the disruption is brief.

Oh, that's a good point, you could even determine that your hypervisor doesn't touch any changed microcode paths, and just pause the VMs, take the update, and unpause. (Still seems... brave, maybe? Or at least involves more information that I'd expect anyone outside of intel to actually have, I guess.)