5 ms·

"A non-disruptive hotload microcode update" a what? I've only seen microcode updates as a boot-time side path, how "hot" is this hotload?

by eichin 3y ago

Aldqueath 3y ago
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
- magnat 3y ago
  > 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.
  - mratsim 3y ago
    Was TSX ever used? I didn't even see an ounce of dev documentation about it.
    - magnat 3y ago
      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-Tunables.html https://www.gnu.org/software/libc/manual/html_node/Elision-T...
  - amluto 3y ago
    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.
toast0 3y ago
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.
- eichin 3y ago
  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.)

"A non-disruptive hotload microcode update" a what? I've only seen microcode updates as a boot-time side path, how "hot" is this hotload?

by eichin 3y ago

"A non-disruptive hotload microcode update" a what? I've only seen microcode updates as a boot-time side path, how "hot" is this hotload?

Aldqueath 3y ago

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

magnat 3y ago
> 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.
- mratsim 3y ago
  Was TSX ever used? I didn't even see an ounce of dev documentation about it.
  - magnat 3y ago
    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-Tunables.html https://www.gnu.org/software/libc/manual/html_node/Elision-T...
- amluto 3y ago
  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.

toast0 3y ago

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.

eichin 3y ago
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.)