[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o72klylj.ffs@tglx>
Date: Wed, 13 Nov 2024 02:19:20 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Patryk Wlazlyn <patryk.wlazlyn@...ux.intel.com>, Peter Zijlstra
<peterz@...radead.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
rafael.j.wysocki@...el.com, len.brown@...el.com,
artem.bityutskiy@...ux.intel.com, dave.hansen@...ux.intel.com
Subject: Re: [PATCH v3 0/3] SRF: Fix offline CPU preventing pc6 entry
On Tue, Nov 12 2024 at 16:43, Patryk Wlazlyn wrote:
>> 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.
That's not really working:
1) Regular kexec offlines them again.
2) Kexec in panic can't do any of that.
Thanks
tglx
Powered by blists - more mailing lists