Messages in this thread | ![/](/images/icornerl.gif) | | From | Thomas Gleixner <> | Subject | Re: [patch v3 5/7] x86/smp: Cure kexec() vs. mwait_play_dead() breakage | Date | Tue, 20 Jun 2023 14:25:48 +0200 |
| |
On Tue, Jun 20 2023 at 11:23, Borislav Petkov wrote: > On Thu, Jun 15, 2023 at 10:33:57PM +0200, Thomas Gleixner wrote: >> TLDR: It's a mess. >> while (1) { >> @@ -1824,10 +1836,57 @@ static inline void mwait_play_dead(void) > > JFYI: that last hunk has some conflicts applying to latest tip/master. > Might need merge resolving...
Yes, I know.
>> +/* >> + * Kick all "offline" CPUs out of mwait on kexec(). See comment in >> + * mwait_play_dead(). >> + */ >> +void smp_kick_mwait_play_dead(void) >> +{ >> + u32 newstate = CPUDEAD_MWAIT_KEXEC_HLT; > > Do you even need this newstate thing?
Yes, for two reasons:
1) To explicitely tell the other CPU to go into HLT. MWAIT can resume execution due to SMIs or NMIs, so we don't want to go them into HLT unconditionally. TLD; .... :)
2) Two have the state feedback from the other CPU.
>> + >> + if (READ_ONCE(md->status) != newstate) >> + pr_err("CPU%u is stuck in mwait_play_dead()\n", cpu); > > Shouldn't this be a pr_err_once thing so that it doesn't flood the > console unnecessarily?
Yes, no, do not know :)
| ![\](/images/icornerr.gif) |