Messages in this thread |  | | Date | Fri, 6 Sep 2019 07:40:39 -0700 | From | Johannes Erdfelt <> | Subject | Re: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged |
| |
On Fri, Sep 06, 2019, Thomas Gleixner <tglx@linutronix.de> wrote: > What your customers are asking for is a receipe for disaster. They can > check the safety of late loading forever, it will not magically become safe > because they do so. > > If you want late loading, then the whole approach needs to be reworked from > ground up. You need to make sure that all CPUs are in a safe state, > i.e. where switching of CPU feature bits of all sorts can be done with the > guarantee that no CPU will return to the wrong code path after coming out > of safe state and that any kernel internal state which depends on the > previous set of CPU feature bits has been mopped up and switched over > before CPUs are released.
You say that switching of CPU feature bits is problematic, but adding new features should result only in a warning ("x86/CPU: CPU features have changed after loading microcode, but might not take effect.").
Removing a CPU feature bit could be problematic. Other than HLE being removed on Haswell (which the kernel shouldn't use anyway), have there been any other cases?
I ask because we have successfully used late microcode loading on tens of thousands of hosts. I'm a bit worried to see that there is a push to remove a feature that we currently rely on.
JE
|  |