<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/x86/kernel/cpu/microcode, branch v4.16</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>x86/microcode: Fix CPU synchronization routine</title>
<updated>2018-03-16T19:55:51+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2018-03-14T18:36:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bb8c13d61a629276a162c1d2b1a20a815cbcfbb7'/>
<id>bb8c13d61a629276a162c1d2b1a20a815cbcfbb7</id>
<content type='text'>
Emanuel reported an issue with a hang during microcode update because my
dumb idea to use one atomic synchronization variable for both rendezvous
- before and after update - was simply bollocks:

  microcode: microcode_reload_late: late_cpus: 4
  microcode: __reload_late: cpu 2 entered
  microcode: __reload_late: cpu 1 entered
  microcode: __reload_late: cpu 3 entered
  microcode: __reload_late: cpu 0 entered
  microcode: __reload_late: cpu 1 left
  microcode: Timeout while waiting for CPUs rendezvous, remaining: 1

CPU1 above would finish, leave and the others will still spin waiting for
it to join.

So do two synchronization atomics instead, which makes the code a lot more
straightforward.

Also, since the update is serialized and it also takes quite some time per
microcode engine, increase the exit timeout by the number of CPUs on the
system.

That's ok because the moment all CPUs are done, that timeout will be cut
short.

Furthermore, panic when some of the CPUs timeout when returning from a
microcode update: we can't allow a system with not all cores updated.

Also, as an optimization, do not do the exit sync if microcode wasn't
updated.

Reported-by: Emanuel Czirai &lt;xftroxgpx@protonmail.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Emanuel Czirai &lt;xftroxgpx@protonmail.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lkml.kernel.org/r/20180314183615.17629-2-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Emanuel reported an issue with a hang during microcode update because my
dumb idea to use one atomic synchronization variable for both rendezvous
- before and after update - was simply bollocks:

  microcode: microcode_reload_late: late_cpus: 4
  microcode: __reload_late: cpu 2 entered
  microcode: __reload_late: cpu 1 entered
  microcode: __reload_late: cpu 3 entered
  microcode: __reload_late: cpu 0 entered
  microcode: __reload_late: cpu 1 left
  microcode: Timeout while waiting for CPUs rendezvous, remaining: 1

CPU1 above would finish, leave and the others will still spin waiting for
it to join.

So do two synchronization atomics instead, which makes the code a lot more
straightforward.

Also, since the update is serialized and it also takes quite some time per
microcode engine, increase the exit timeout by the number of CPUs on the
system.

That's ok because the moment all CPUs are done, that timeout will be cut
short.

Furthermore, panic when some of the CPUs timeout when returning from a
microcode update: we can't allow a system with not all cores updated.

Also, as an optimization, do not do the exit sync if microcode wasn't
updated.

Reported-by: Emanuel Czirai &lt;xftroxgpx@protonmail.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Emanuel Czirai &lt;xftroxgpx@protonmail.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lkml.kernel.org/r/20180314183615.17629-2-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode: Attempt late loading only when new microcode is present</title>
<updated>2018-03-16T19:55:51+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2018-03-14T18:36:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2613f36ed965d0e5a595a1d931fd3b480e82d6fd'/>
<id>2613f36ed965d0e5a595a1d931fd3b480e82d6fd</id>
<content type='text'>
Return UCODE_NEW from the scanning functions to denote that new microcode
was found and only then attempt the expensive synchronization dance.

Reported-by: Emanuel Czirai &lt;xftroxgpx@protonmail.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Emanuel Czirai &lt;xftroxgpx@protonmail.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lkml.kernel.org/r/20180314183615.17629-1-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Return UCODE_NEW from the scanning functions to denote that new microcode
was found and only then attempt the expensive synchronization dance.

Reported-by: Emanuel Czirai &lt;xftroxgpx@protonmail.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Emanuel Czirai &lt;xftroxgpx@protonmail.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lkml.kernel.org/r/20180314183615.17629-1-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode: Synchronize late microcode loading</title>
<updated>2018-03-08T09:19:26+00:00</updated>
<author>
<name>Ashok Raj</name>
<email>ashok.raj@intel.com</email>
</author>
<published>2018-02-28T10:28:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a5321aec6412b20b5ad15db2d6b916c05349dbff'/>
<id>a5321aec6412b20b5ad15db2d6b916c05349dbff</id>
<content type='text'>
Original idea by Ashok, completely rewritten by Borislav.

Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.

Gather all cores and serialize the microcode update on them by doing it
one-by-one to make the late update process as reliable as possible and
avoid potential issues caused by the microcode update.

[ Borislav: Rewrite completely. ]

Co-developed-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: https://lkml.kernel.org/r/20180228102846.13447-8-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Original idea by Ashok, completely rewritten by Borislav.

Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.

Gather all cores and serialize the microcode update on them by doing it
one-by-one to make the late update process as reliable as possible and
avoid potential issues caused by the microcode update.

[ Borislav: Rewrite completely. ]

Co-developed-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: https://lkml.kernel.org/r/20180228102846.13447-8-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode: Request microcode on the BSP</title>
<updated>2018-03-08T09:19:26+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2018-02-28T10:28:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cfb52a5a09c8ae3a1dafb44ce549fde5b69e8117'/>
<id>cfb52a5a09c8ae3a1dafb44ce549fde5b69e8117</id>
<content type='text'>
... so that any newer version can land in the cache and can later be
fished out by the application functions. Do that before grabbing the
hotplug lock.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: https://lkml.kernel.org/r/20180228102846.13447-7-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
... so that any newer version can land in the cache and can later be
fished out by the application functions. Do that before grabbing the
hotplug lock.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: https://lkml.kernel.org/r/20180228102846.13447-7-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode/intel: Look into the patch cache first</title>
<updated>2018-03-08T09:19:26+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2018-02-28T10:28:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d8c3b52c00a05036e0a6b315b4b17921a7b67997'/>
<id>d8c3b52c00a05036e0a6b315b4b17921a7b67997</id>
<content type='text'>
The cache might contain a newer patch - look in there first.

A follow-on change will make sure newest patches are loaded into the
cache of microcode patches.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: https://lkml.kernel.org/r/20180228102846.13447-6-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The cache might contain a newer patch - look in there first.

A follow-on change will make sure newest patches are loaded into the
cache of microcode patches.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: https://lkml.kernel.org/r/20180228102846.13447-6-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode: Do not upload microcode if CPUs are offline</title>
<updated>2018-03-08T09:19:26+00:00</updated>
<author>
<name>Ashok Raj</name>
<email>ashok.raj@intel.com</email>
</author>
<published>2018-02-28T10:28:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=30ec26da9967d0d785abc24073129a34c3211777'/>
<id>30ec26da9967d0d785abc24073129a34c3211777</id>
<content type='text'>
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.

[ Borislav: Massage changelog. ]

Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: http://lkml.kernel.org/r/1519352533-15992-4-git-send-email-ashok.raj@intel.com
Link: https://lkml.kernel.org/r/20180228102846.13447-5-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.

[ Borislav: Massage changelog. ]

Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: http://lkml.kernel.org/r/1519352533-15992-4-git-send-email-ashok.raj@intel.com
Link: https://lkml.kernel.org/r/20180228102846.13447-5-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode/intel: Writeback and invalidate caches before updating microcode</title>
<updated>2018-03-08T09:19:25+00:00</updated>
<author>
<name>Ashok Raj</name>
<email>ashok.raj@intel.com</email>
</author>
<published>2018-02-28T10:28:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=91df9fdf51492aec9fed6b4cbd33160886740f47'/>
<id>91df9fdf51492aec9fed6b4cbd33160886740f47</id>
<content type='text'>
Updating microcode is less error prone when caches have been flushed and
depending on what exactly the microcode is updating. For example, some
of the issues around certain Broadwell parts can be addressed by doing a
full cache flush.

[ Borislav: Massage it and use native_wbinvd() in both cases. ]

Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: http://lkml.kernel.org/r/1519352533-15992-3-git-send-email-ashok.raj@intel.com
Link: https://lkml.kernel.org/r/20180228102846.13447-4-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Updating microcode is less error prone when caches have been flushed and
depending on what exactly the microcode is updating. For example, some
of the issues around certain Broadwell parts can be addressed by doing a
full cache flush.

[ Borislav: Massage it and use native_wbinvd() in both cases. ]

Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: http://lkml.kernel.org/r/1519352533-15992-3-git-send-email-ashok.raj@intel.com
Link: https://lkml.kernel.org/r/20180228102846.13447-4-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode/intel: Check microcode revision before updating sibling threads</title>
<updated>2018-03-08T09:19:25+00:00</updated>
<author>
<name>Ashok Raj</name>
<email>ashok.raj@intel.com</email>
</author>
<published>2018-02-28T10:28:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c182d2b7d0ca48e0d6ff16f7d883161238c447ed'/>
<id>c182d2b7d0ca48e0d6ff16f7d883161238c447ed</id>
<content type='text'>
After updating microcode on one of the threads of a core, the other
thread sibling automatically gets the update since the microcode
resources on a hyperthreaded core are shared between the two threads.

Check the microcode revision on the CPU before performing a microcode
update and thus save us the WRMSR 0x79 because it is a particularly
expensive operation.

[ Borislav: Massage changelog and coding style. ]

Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: http://lkml.kernel.org/r/1519352533-15992-2-git-send-email-ashok.raj@intel.com
Link: https://lkml.kernel.org/r/20180228102846.13447-3-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After updating microcode on one of the threads of a core, the other
thread sibling automatically gets the update since the microcode
resources on a hyperthreaded core are shared between the two threads.

Check the microcode revision on the CPU before performing a microcode
update and thus save us the WRMSR 0x79 because it is a particularly
expensive operation.

[ Borislav: Massage changelog and coding style. ]

Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: http://lkml.kernel.org/r/1519352533-15992-2-git-send-email-ashok.raj@intel.com
Link: https://lkml.kernel.org/r/20180228102846.13447-3-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/microcode: Get rid of struct apply_microcode_ctx</title>
<updated>2018-03-08T09:19:25+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2018-02-28T10:28:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=854857f5944c59a881ff607b37ed9ed41d031a3b'/>
<id>854857f5944c59a881ff607b37ed9ed41d031a3b</id>
<content type='text'>
It is a useless remnant from earlier times. Use the ucode_state enum
directly.

No functional change.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: https://lkml.kernel.org/r/20180228102846.13447-2-bp@alien8.de

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is a useless remnant from earlier times. Use the ucode_state enum
directly.

No functional change.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Arjan Van De Ven &lt;arjan.van.de.ven@intel.com&gt;
Link: https://lkml.kernel.org/r/20180228102846.13447-2-bp@alien8.de

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/CPU: Add a microcode loader callback</title>
<updated>2018-02-17T07:43:55+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2018-02-16T11:26:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1008c52c09dcb23d93f8e0ea83a6246265d2cce0'/>
<id>1008c52c09dcb23d93f8e0ea83a6246265d2cce0</id>
<content type='text'>
Add a callback function which the microcode loader calls when microcode
has been updated to a newer revision. Do the callback only when no error
was encountered during loading.

Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/20180216112640.11554-3-bp@alien8.de
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a callback function which the microcode loader calls when microcode
has been updated to a newer revision. Do the callback only when no error
was encountered during loading.

Tested-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/20180216112640.11554-3-bp@alien8.de
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
