Add Intel Lunarlake to X86_BUG_MONITOR

From: Len Brown <[email protected]>

Under some conditions, MONITOR wakeups on Lunar Lake processors can be lost, resulting in significant user-visible delays.

Add LunarLake to X86_BUG_MONITOR so that wake_up_idle_cpu() always sends an IPI, avoiding this potential delay. Update the X86_BUG_MONITOR workaround to handle the new smp_kick_mwait_play_dead() path.

Closes https://bugzilla.kernel.org/show_bug.cgi?id=219364

Cc [email protected] # 6.10

Signed-off-by Len Brown <[email protected]>

---
This is a backport of the upstream patch to Linux-6.10 and earlier

From: Len Brown <[email protected]>

Under some conditions, MONITOR wakeups on Lunar Lake processors can be lost, resulting in significant user-visible delays.

Add LunarLake to X86_BUG_MONITOR so that wake_up_idle_cpu() always sends an IPI, avoiding this potential delay.

Also update the X86_BUG_MONITOR workaround to handle the new smp_kick_mwait_play_dead() path.

Closes https://bugzilla.kernel.org/show_bug.cgi?id=219364

Cc [email protected] # 6.11

Signed-off-by Len Brown <[email protected]>

---
 arch/x86/kernel/cpu/intel.c | 3 ++-
 arch/x86/kernel/smpboot.c   | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

arch/x86/kernel/cpu/intel.c +2 -1

index e7656cbef68d..aa63f5f780a0 100644
@@ -586,7 +586,8 @@ static void init_intel(struct cpuinfo_x86 *c)
             c->x86_vfm == INTEL_WESTMERE_EX))
                set_cpu_bug(c, X86_BUG_CLFLUSH_MONITOR);
 
-       if (boot_cpu_has(X86_FEATURE_MWAIT) && c->x86_vfm == INTEL_ATOM_GOLDMONT)
+       if (boot_cpu_has(X86_FEATURE_MWAIT) &&
+                       (c->x86_vfm == INTEL_ATOM_GOLDMONT || c->x86_vfm == INTEL_LUNARLAKE_M))
                set_cpu_bug(c, X86_BUG_MONITOR);
 
 #ifdef CONFIG_X86_64

arch/x86/kernel/smpboot.c +0 -0

index 766f092dab80..910cb2d72c13 100644

arch/x86/kernel/smpboot.c +0 -1

                        udelay(5);
                }
 
--

arch/x86/kernel/smpboot.c void smp_kick_mwait_play_dead(void) · line 1384

Quoted 13 lines · Len Brown

arch/x86/kernel/smpboot.c +3 -0

index 766f092dab80..910cb2d72c13 100644
@@ -1377,6 +1377,9 @@ void smp_kick_mwait_play_dead(void)
 		for (i = 0; READ_ONCE(md->status) != newstate && i < 1000; i++) {
 			/* Bring it out of mwait */
 			WRITE_ONCE(md->control, newstate);
+			/* If MONITOR unreliable, send IPI */
+			if (boot_cpu_has_bug(X86_BUG_MONITOR))
+				__apic_send_IPI(cpu, RESCHEDULE_VECTOR);
 			udelay(5);
 		}

Going over that code again, mwait_play_dead() is doing __mwait(.exc=0) with IRQs disabled.

So that IPI you're trying to send there won't do no nothing :-/

Now that comment there says MCE/NMI/SMI are still open (non-maskable etc.) so perhaps prod it on the NMI vector?

This does seem to suggest the above code path wasn't actually tested.

Perhaps mark your local machine with BUG_MONITOR, remove the md->control WRITE_ONCE() and try kexec to test it?

Thomas, any other thoughts?

From: Len Brown <[email protected]>

Under some conditions, MONITOR wakeups on Lunar Lake processors can be lost, resulting in significant user-visible delays.

Add LunarLake to X86_BUG_MONITOR so that wake_up_idle_cpu() always sends an IPI, avoiding this potential delay.

Closes https://bugzilla.kernel.org/show_bug.cgi?id=219364

Cc [email protected] # 6.11

Signed-off-by Len Brown <[email protected]>

---
 arch/x86/kernel/cpu/intel.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

arch/x86/kernel/cpu/intel.c +0 -0

index e7656cbef68d..284cd561499c 100644

arch/x86/kernel/cpu/intel.c +2 -1

+           (c->x86_vfm == INTEL_ATOM_GOLDMONT ||
+            c->x86_vfm == INTEL_LUNARLAKE_M))
 
                set_cpu_bug(c, X86_BUG_MONITOR);
 
 #ifdef CONFIG_X86_64
--

2.43.0

Quoted 5 lines · Rafael J. Wysocki

Quoted 4 lines

arch/x86/kernel/cpu/intel.c +3 -1

-       if (boot_cpu_has(X86_FEATURE_MWAIT) && c->x86_vfm == INTEL_ATOM_GOLDMONT)
+       if (boot_cpu_has(X86_FEATURE_MWAIT) &&
+           (c->x86_vfm == INTEL_ATOM_GOLDMONT
+            || c->x86_vfm == INTEL_LUNARLAKE_M))

Quoted 1 line

I would put the || at the end of the previous line, that is

It isn't my personal preference for human readability either, but this is what scripts/Lindent does...

Quoted 10 lines · Rafael J. Wysocki

Quoted 8 lines · Len Brown

Quoted 5 lines · Rafael J. Wysocki

Quoted 4 lines

arch/x86/kernel/cpu/intel.c +3 -1

-       if (boot_cpu_has(X86_FEATURE_MWAIT) && c->x86_vfm == INTEL_ATOM_GOLDMONT)
+       if (boot_cpu_has(X86_FEATURE_MWAIT) &&
+           (c->x86_vfm == INTEL_ATOM_GOLDMONT
+            || c->x86_vfm == INTEL_LUNARLAKE_M))

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

I would put the || at the end of the previous line, that is

It isn't my personal preference for human readability either, but this is what scripts/Lindent does...

Well, it doesn't match the coding style of the first line ...

Fair observation.

I'll bite.

If you took the existing intel.c and added it as a patch to the kernel, the resulting checkpatch would have 6 errors and 33 warnings.

If you ran Lindent on the existing intel.c, the resulting diff would be 408 lines -- 1 file changed, 232 insertions(+), 176 deletions(-)

This for a file that is only 1300 lines long.

If whitespace nirvana is the goal, tools are the answer, not the valuable cycles of human reviewers.