Re: [PATCH] x86/cpu: Add INTEL_LUNARLAKE_M to X86_BUG_MONITOR
From: Rafael J. Wysocki
Date: Fri Nov 08 2024 - 09:35:12 EST
On Fri, Nov 8, 2024 at 2:52 PM Len Brown <lenb@xxxxxxxxxx> wrote:
>
> From: Len Brown <len.brown@xxxxxxxxx>
>
> 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: stable@xxxxxxxxxxxxxxx # 6.11
> Signed-off-by: Len Brown <len.brown@xxxxxxxxx>
Overall
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> ---
> arch/x86/kernel/cpu/intel.c | 3 ++-
> arch/x86/kernel/smpboot.c | 3 +++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index e7656cbef68d..aa63f5f780a0 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -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
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 766f092dab80..910cb2d72c13 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -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);
The __apic_send_IPI() call could be wrapped into something like
__native_smp_send_reschedule() to underline the analogy between this
and what happens in native_smp_send_reschedule().
It is still fine as is though IMV.
> udelay(5);
> }
>
> --