lkml.org 
[lkml]   [2023]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch v3 5/7] x86/smp: Cure kexec() vs. mwait_play_dead() breakage
Date
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 :)

\
 
 \ /
  Last update: 2023-06-20 14:26    [W:0.138 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site