[jeffbee]

The updates are often fatal, though. These include things like the Opteron "Barcelona" TLB bug and the first-generation EPYC "Naples" frequency scaling bug. The fix for the former knocked 20% off the performance of that generation of parts, and the fix for the latter meant that you had to run at the base clock frequency at all times, getting neither turbo boosts nor power savings. If you apply all of the speculative execution workarounds to an older Intel part like Xeon E5 v3 you will lose something like a quarter of the performance you paid for originally.

[bombcar]

Yeah, I was thinking more of architecture errors where the solution is “modify the compiler so that code isn’t called” - though some may allow microcode updates.

The various spec-ex workarounds actually matter more on things like cloud servers than they do on dedicated/controlled hardware.

[mrslave]

When microcode is so small (2K according [0]) how can it work to enable/disable specific instructions, or even change how they work?

[0] https://en.wikipedia.org/wiki/Intel_Microcode

[Liquid_Fire]

If I'm reading that page right, the update is 2 kB but it does not contain a full set of microcode, only some sort of patch e.g. only for the instructions that need fixes.

[mrslave]

Interesting. So a CPU at version N is updated by a sequence of N patches applied in order, where each patch is a pair of location and code-as-data, plus noise (gotta confuse the competition, and hackers I guess).

[opencl]

There's a base microcode in ROM and the patches are stored in a small piece of RAM built into the CPU, the whole sequence of patches is applied on every boot. Generally the BIOS will apply all the patches it has stored and then the OS will finish the sequence if the BIOS version wasn't already the latest.

It's a long list for some CPUs, i.e. Sandy Bridge was released in 2011 and got its most recent microcode update in 2020.