Message ID | 20241108122909.763663-1-patryk.wlazlyn@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | SRF: Fix offline CPU preventing pc6 entry | expand |
On 11/8/24 04:29, Patryk Wlazlyn wrote:
> Applied suggestions from Dave and Rafael.
The basic approach here is looking pretty sound, so thanks for that
Patryk. I mostly have mechanical nits left.
On Fri, Nov 08, 2024 at 01:29:06PM +0100, Patryk Wlazlyn wrote: > Removing the existing "kexec hack" by bringing all offlined CPUs back > online before proceeding with the kexec would make it even simpler, but > I am not sure we can do that. It looks kind of obvious to me, but for > some reason the hack exist. There's a comment there that explains why this is done. If you don't understand this, then please don't touch this code.
> There's a comment there that explains why this is done. If you don't > understand this, then please don't touch this code. /* * Kexec is about to happen. Don't go back into mwait() as * the kexec kernel might overwrite text and data including * page tables and stack. So mwait() would resume when the * monitor cache line is written to and then the CPU goes * south due to overwritten text, page tables and stack. * * Note: This does _NOT_ protect against a stray MCE, NMI, * SMI. They will resume execution at the instruction * following the HLT instruction and run into the problem * which this is trying to prevent. */ If you are referring to this comment above, I do understand the need to enter hlt loop before the kexec happens. I thought that I could bring all of the offlined CPUs back online, effectively getting them out of the mwait loop.