Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12 |
|
#
d86c51e9 |
| 15-Jan-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
x86/microcode: do not cache microcode if it will not be used
No relevant upstream kernel due to refactoring in 6.7
Builtin/initrd microcode will not be used the ucode loader is disabled. But curren
x86/microcode: do not cache microcode if it will not be used
No relevant upstream kernel due to refactoring in 6.7
Builtin/initrd microcode will not be used the ucode loader is disabled. But currently, save_microcode_in_initrd is always performed and it accesses MSR_IA32_UCODE_REV even if dis_ucode_ldr is true, and in particular even if X86_FEATURE_HYPERVISOR is set; the TDX module does not implement the MSR and the result is a call trace at boot for TDX guests.
Mainline Linux fixed this as part of a more complex rework of microcode caching that went into 6.7 (see in particular commits dd5e3e3ca6, "x86/microcode/intel: Simplify early loading"; and a7939f0167203, "x86/microcode/amd: Cache builtin/initrd microcode early"). Do the bare minimum in stable kernels, setting initrd_gone just like mainline Linux does in mark_initrd_gone().
Note that save_microcode_in_initrd() is not in the microcode application path, which runs with paging disabled on 32-bit systems, so it can (and has to) use dis_ucode_ldr instead of check_loader_disabled_ap().
Cc: stable@vger.kernel.org # v6.6+ Cc: x86@kernel.org # v6.6+ Cc: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46 |
|
#
d02a0efd |
| 12-Aug-2023 |
Thomas Gleixner <tglx@linutronix.de> |
x86/microcode: Move core specific defines to local header
There is no reason to expose all of this globally. Move everything which is not required outside of the microcode specific code to local hea
x86/microcode: Move core specific defines to local header
There is no reason to expose all of this globally. Move everything which is not required outside of the microcode specific code to local header files and into the respective source files.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230812195727.952876381@linutronix.de
show more ...
|
#
18648dbd |
| 12-Aug-2023 |
Thomas Gleixner <tglx@linutronix.de> |
x86/microcode: Make reload_early_microcode() static
fe055896c040 ("x86/microcode: Merge the early microcode loader") left this needlessly public. Git archaeology provided by Borislav.
Signed-off-by
x86/microcode: Make reload_early_microcode() static
fe055896c040 ("x86/microcode: Merge the early microcode loader") left this needlessly public. Git archaeology provided by Borislav.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230812195727.834943153@linutronix.de
show more ...
|
#
82ad097b |
| 12-Aug-2023 |
Ashok Raj <ashok.raj@intel.com> |
x86/microcode: Include vendor headers into microcode.h
Currently vendor specific headers are included explicitly when used in common code. Instead, include the vendor specific headers in microcode.h
x86/microcode: Include vendor headers into microcode.h
Currently vendor specific headers are included explicitly when used in common code. Instead, include the vendor specific headers in microcode.h, and include that in all usages.
No functional change.
Suggested-by: Boris Petkov <bp@alien8.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230812195727.776541545@linutronix.de
show more ...
|
Revision tags: v6.1.45, v6.1.44 |
|
#
80347cd5 |
| 04-Aug-2023 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
x86/microcode: Remove microcode_mutex
microcode_mutex is only used by reload_store(). It has a comment saying "to synchronize with each other". Other user of this mutex have been removed in the comm
x86/microcode: Remove microcode_mutex
microcode_mutex is only used by reload_store(). It has a comment saying "to synchronize with each other". Other user of this mutex have been removed in the commits
181b6f40e9ea8 ("x86/microcode: Rip out the OLD_INTERFACE"). b6f86689d5b74 ("x86/microcode: Rip out the subsys interface gunk")
The sysfs interface does not need additional synchronisation vs itself because it is provided as kernfs_ops::mutex which is acquired in kernfs_fop_write_iter().
Remove the superfluous microcode_mutex.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20230804075853.JF_n6GXC@linutronix.de
show more ...
|
Revision tags: v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33 |
|
#
05e91e72 |
| 07-Jun-2023 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/microcode/AMD: Rip out static buffers
Load straight from the containers (initrd or builtin, for example). There's no need to cache the patch per node.
This even simplifies the code a bit with t
x86/microcode/AMD: Rip out static buffers
Load straight from the containers (initrd or builtin, for example). There's no need to cache the patch per node.
This even simplifies the code a bit with the opportunity for more cleanups later.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: John Allen <john.allen@amd.com> Link: https://lore.kernel.org/r/20230720202813.3269888-1-john.allen@amd.com
show more ...
|
Revision tags: v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20 |
|
#
216f58be |
| 13-Mar-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
x86/microcode: move to use bus_get_dev_root()
Direct access to the struct bus_type dev_root pointer is going away soon so replace that with a call to bus_get_dev_root() instead, which is what it is
x86/microcode: move to use bus_get_dev_root()
Direct access to the struct bus_type dev_root pointer is going away soon so replace that with a call to bus_get_dev_root() instead, which is what it is there for.
Cc: Borislav Petkov <bp@alien8.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: x86@kernel.org Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lore.kernel.org/r/20230313182918.1312597-9-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9 |
|
#
f33e0c89 |
| 30-Jan-2023 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/microcode/core: Return an error only when necessary
Return an error from the late loading function which is run on each CPU only when an error has actually been encountered during the update.
S
x86/microcode/core: Return an error only when necessary
Return an error from the late loading function which is run on each CPU only when an error has actually been encountered during the update.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230130161709.11615-5-bp@alien8.de
show more ...
|
#
a5ad9213 |
| 25-Jan-2023 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/microcode/AMD: Add a @cpu parameter to the reloading functions
Will be used in a subsequent change.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/202301301
x86/microcode/AMD: Add a @cpu parameter to the reloading functions
Will be used in a subsequent change.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230130161709.11615-3-bp@alien8.de
show more ...
|
#
25d0dc4b |
| 30-Jan-2023 |
Ashok Raj <ashok.raj@intel.com> |
x86/microcode: Allow only "1" as a late reload trigger value
Microcode gets reloaded late only if "1" is written to the reload file. However, the code silently treats any other unsigned integer as a
x86/microcode: Allow only "1" as a late reload trigger value
Microcode gets reloaded late only if "1" is written to the reload file. However, the code silently treats any other unsigned integer as a successful write even though no actions are performed to load microcode.
Make the loader more strict to accept only "1" as a trigger value and return an error otherwise.
[ bp: Massage commit message. ]
Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230130213955.6046-3-ashok.raj@intel.com
show more ...
|
Revision tags: v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19 |
|
#
6eab3aba |
| 09-Jan-2023 |
Ashok Raj <ashok.raj@intel.com> |
x86/microcode: Adjust late loading result reporting message
During late microcode loading, the "Reload completed" message is issued unconditionally, regardless of success or failure.
Adjust the mes
x86/microcode: Adjust late loading result reporting message
During late microcode loading, the "Reload completed" message is issued unconditionally, regardless of success or failure.
Adjust the message to report the result of the update.
[ bp: Massage. ]
Fixes: 9bd681251b7c ("x86/microcode: Announce reload operation's completion") Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/lkml/874judpqqd.ffs@tglx/
show more ...
|
#
c0dd9245 |
| 09-Jan-2023 |
Ashok Raj <ashok.raj@intel.com> |
x86/microcode: Check CPU capabilities after late microcode update correctly
The kernel caches each CPU's feature bits at boot in an x86_capability[] structure. However, the capabilities in the BSP's
x86/microcode: Check CPU capabilities after late microcode update correctly
The kernel caches each CPU's feature bits at boot in an x86_capability[] structure. However, the capabilities in the BSP's copy can be turned off as a result of certain command line parameters or configuration restrictions, for example the SGX bit. This can cause a mismatch when comparing the values before and after the microcode update.
Another example is X86_FEATURE_SRBDS_CTRL which gets added only after microcode update:
--- cpuid.before 2023-01-21 14:54:15.652000747 +0100 +++ cpuid.after 2023-01-21 14:54:26.632001024 +0100 @@ -10,7 +10,7 @@ CPU: 0x00000004 0x04: eax=0x00000000 ebx=0x00000000 ecx=0x00000000 edx=0x00000000 0x00000005 0x00: eax=0x00000040 ebx=0x00000040 ecx=0x00000003 edx=0x11142120 0x00000006 0x00: eax=0x000027f7 ebx=0x00000002 ecx=0x00000001 edx=0x00000000 - 0x00000007 0x00: eax=0x00000000 ebx=0x029c6fbf ecx=0x40000000 edx=0xbc002400 + 0x00000007 0x00: eax=0x00000000 ebx=0x029c6fbf ecx=0x40000000 edx=0xbc002e00 ^^^
and which proves for a gazillionth time that late loading is a bad bad idea.
microcode_check() is called after an update to report any previously cached CPUID bits which might have changed due to the update.
Therefore, store the cached CPU caps before the update and compare them with the CPU caps after the microcode update has succeeded.
Thus, the comparison is done between the CPUID *hardware* bits before and after the upgrade instead of using the cached, possibly runtime modified values in BSP's boot_cpu_data copy.
As a result, false warnings about CPUID bits changes are avoided.
[ bp: - Massage. - Add SRBDS_CTRL example. - Add kernel-doc. - Incorporate forgotten review feedback from dhansen. ]
Fixes: 1008c52c09dc ("x86/CPU: Add a microcode loader callback") Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230109153555.4986-3-ashok.raj@intel.com
show more ...
|
#
ab31c744 |
| 09-Jan-2023 |
Ashok Raj <ashok.raj@intel.com> |
x86/microcode: Add a parameter to microcode_check() to store CPU capabilities
Add a parameter to store CPU capabilities before performing a microcode update so that CPU capabilities can be compared
x86/microcode: Add a parameter to microcode_check() to store CPU capabilities
Add a parameter to store CPU capabilities before performing a microcode update so that CPU capabilities can be compared before and after update.
[ bp: Massage. ]
Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230109153555.4986-2-ashok.raj@intel.com
show more ...
|
#
59047d94 |
| 17-Jan-2023 |
Guangju Wang[baidu] <wgj900@163.com> |
x86/microcode: Use the DEVICE_ATTR_RO() macro
Use DEVICE_ATTR_RO() helper instead of open-coded DEVICE_ATTR(), which makes the code a bit shorter and easier to read.
No change in functionality.
Si
x86/microcode: Use the DEVICE_ATTR_RO() macro
Use DEVICE_ATTR_RO() helper instead of open-coded DEVICE_ATTR(), which makes the code a bit shorter and easier to read.
No change in functionality.
Signed-off-by: Guangju Wang[baidu] <wgj900@163.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230118023554.1898-1-wgj900@163.com
show more ...
|
Revision tags: v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3 |
|
#
254ed7cf |
| 19-Oct-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Drop struct ucode_cpu_info.valid
It is not needed anymore.
Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/20
x86/microcode: Drop struct ucode_cpu_info.valid
It is not needed anymore.
Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/20221028142638.28498-6-bp@alien8.de
show more ...
|
#
2e6ff405 |
| 19-Oct-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Do some minor fixups
Improve debugging printks and fixup formatting.
Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kerne
x86/microcode: Do some minor fixups
Improve debugging printks and fixup formatting.
Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/20221028142638.28498-5-bp@alien8.de
show more ...
|
#
a61ac80a |
| 19-Oct-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Kill refresh_fw
request_microcode_fw() can always request firmware now so drop this superfluous argument.
Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.ra
x86/microcode: Kill refresh_fw
request_microcode_fw() can always request firmware now so drop this superfluous argument.
Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/20221028142638.28498-4-bp@alien8.de
show more ...
|
#
2071c0ae |
| 19-Oct-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Simplify init path even more
Get rid of all the IPI-sending functions and their wrappers and use those which are supposed to be called on each CPU.
Thus:
- microcode_init_cpu() gets
x86/microcode: Simplify init path even more
Get rid of all the IPI-sending functions and their wrappers and use those which are supposed to be called on each CPU.
Thus:
- microcode_init_cpu() gets called on each CPU on init, applying any new microcode that the driver might've found on the filesystem.
- mc_cpu_starting() simply tries to apply cached microcode as this is the cpuhp starting callback which gets called on CPU resume too.
Even if the driver init function is a late initcall, there is no filesystem by then (not even a hdd driver has been loaded yet) so a new firmware load attempt cannot simply be done.
It is pointless anyway - for that there's late loading if one really needs it.
Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/20221028142638.28498-3-bp@alien8.de
show more ...
|
#
b6f86689 |
| 19-Oct-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Rip out the subsys interface gunk
This is a left-over from the old days when CPU hotplug wasn't as robust as it is now. Currently, microcode gets loaded early on the CPU init path and
x86/microcode: Rip out the subsys interface gunk
This is a left-over from the old days when CPU hotplug wasn't as robust as it is now. Currently, microcode gets loaded early on the CPU init path and there's no need to attempt to load it again, which that subsys interface callback is doing.
The only other thing that the subsys interface init path was doing is adding the
/sys/devices/system/cpu/cpu*/microcode/
hierarchy.
So add a function which gets called on each CPU after all the necessary driver setup has happened. Use schedule_on_each_cpu() which can block because the sysfs creating code does kmem_cache_zalloc() which can block too and the initial version of this where it did that setup in an IPI handler of on_each_cpu() can cause a deadlock of the sort:
lock(fs_reclaim); <Interrupt> lock(fs_reclaim);
as the IPI handler runs in IRQ context.
Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Ashok Raj <ashok.raj@intel.com> Link: https://lore.kernel.org/r/20221028142638.28498-2-bp@alien8.de
show more ...
|
Revision tags: v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64 |
|
#
7fce8d6e |
| 29-Aug-2022 |
Ashok Raj <ashok.raj@intel.com> |
x86/microcode: Print previous version of microcode after reload
Print both old and new versions of microcode after a reload is complete because knowing the previous microcode version is sometimes im
x86/microcode: Print previous version of microcode after reload
Print both old and new versions of microcode after a reload is complete because knowing the previous microcode version is sometimes important from a debugging perspective.
[ bp: Massage commit message. ]
Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20220829181030.722891-1-ashok.raj@intel.com
show more ...
|
Revision tags: v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44 |
|
#
0c0fe08c |
| 25-May-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Remove unnecessary perf callback
c93dc84cbe32 ("perf/x86: Add a microcode revision check for SNB-PEBS") checks whether the microcode revision has fixed PEBS issues.
This can happen e
x86/microcode: Remove unnecessary perf callback
c93dc84cbe32 ("perf/x86: Add a microcode revision check for SNB-PEBS") checks whether the microcode revision has fixed PEBS issues.
This can happen either:
1. At PEBS init time, where the early microcode has been loaded already
2. During late loading, in the microcode_check() callback.
So remove the unnecessary call in the microcode loader init routine.
Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220525161232.14924-5-bp@alien8.de
show more ...
|
#
d23d33ea |
| 25-May-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Taint and warn on late loading
Warn before it is attempted and taint the kernel. Late loading microcode can lead to malfunction of the kernel when the microcode update changes behavio
x86/microcode: Taint and warn on late loading
Warn before it is attempted and taint the kernel. Late loading microcode can lead to malfunction of the kernel when the microcode update changes behaviour. There is no way for the kernel to determine whether its safe or not.
Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220525161232.14924-4-bp@alien8.de
show more ...
|
#
a77a94f8 |
| 25-May-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Default-disable late loading
It is dangerous and it should not be used anyway - there's a nice early loading already.
Requested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Sign
x86/microcode: Default-disable late loading
It is dangerous and it should not be used anyway - there's a nice early loading already.
Requested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220525161232.14924-3-bp@alien8.de
show more ...
|
#
181b6f40 |
| 25-May-2022 |
Borislav Petkov <bp@suse.de> |
x86/microcode: Rip out the OLD_INTERFACE
Everything should be using the early initrd loading by now.
Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
x86/microcode: Rip out the OLD_INTERFACE
Everything should be using the early initrd loading by now.
Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220525161232.14924-2-bp@alien8.de
show more ...
|
Revision tags: v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35 |
|
#
f9e14dbb |
| 19-Apr-2022 |
Borislav Petkov <bp@suse.de> |
x86/cpu: Load microcode during restore_processor_state()
When resuming from system sleep state, restore_processor_state() restores the boot CPU MSRs. These MSRs could be emulated by microcode. If mi
x86/cpu: Load microcode during restore_processor_state()
When resuming from system sleep state, restore_processor_state() restores the boot CPU MSRs. These MSRs could be emulated by microcode. If microcode is not loaded yet, writing to emulated MSRs leads to unchecked MSR access error:
... PM: Calling lapic_suspend+0x0/0x210 unchecked MSR access error: WRMSR to 0x10f (tried to write 0x0...0) at rIP: ... (native_write_msr) Call Trace: <TASK> ? restore_processor_state x86_acpi_suspend_lowlevel acpi_suspend_enter suspend_devices_and_enter pm_suspend.cold state_store kobj_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write __x64_sys_write do_syscall_64 entry_SYSCALL_64_after_hwframe RIP: 0033:0x7fda13c260a7
To ensure microcode emulated MSRs are available for restoration, load the microcode on the boot CPU before restoring these MSRs.
[ Pawan: write commit message and productize it. ]
Fixes: e2a1256b17b1 ("x86/speculation: Restore speculation related MSRs during S3 resume") Reported-by: Kyle D. Pelton <kyle.d.pelton@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Tested-by: Kyle D. Pelton <kyle.d.pelton@intel.com> Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=215841 Link: https://lore.kernel.org/r/4350dfbf785cd482d3fafa72b2b49c83102df3ce.1650386317.git.pawan.kumar.gupta@linux.intel.com
show more ...
|