On Wed, 28 Feb 2018, Raj, Ashok wrote: > On Wed, Feb 28, 2018 at 10:11:56AM -0300, Henrique de Moraes Holschuh wrote: > > > Avoid loading microcode if any of the CPUs are offline, and issue a > > > warning. Having different microcode revisions on the system at any time > > > is outright dangerous. > > > > Even if we update that microcode during CPU early bring-up, before we > > mark it on-line and start using it? > > > > AFAIK, late-loading or not, this is what should happen in the current > > code: APs that are brought up after a microcode update is loaded (either > > by the early or late driver, it doesn't matter) will be always > > *early-updated* to the new microcode. > > > > Is it dangerous to have an offline core at an older microcode revision > > than the online cores? > > We don't want to leave a system and allow the user to update microcode > when some cpus are offline. Remember cpu_offline in linux is only > logical offlining.. so the cpu is still in the system.. it can even > participate in MCE for e.g. It is very much alive. Its not a question > that "Would it not work" but its not worth to leave an open door and > being paranoid is best!
I see. Thanks for the explanation! > > I am not against the patch, mind you, but I am curious about why it is > > supposed to be dangerous if we're updating the CPUs before we start > > using them *anyway*. > > > > Also, if this is really dangerous, does it means safe CPU hotplug isn't > > possible? AFAICT, the firmware would have to do it for us, but it > > *doesn't* have the up-to-date microcode (*we* had to update it)... > > The difference is hot-adding you know you are going to update the current > microcode. But leaving a cpu in offline state is leaving it stale for a long > time without realizing that you have some stale cores. That begs the question: do we have any reasons to not update the microcode even the offline cores? -- Henrique Holschuh