[PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Yureka Lilian]

Overriding the idle mechanism might be useful for debugging and performance
testing. Add a cmdline parameter for it, similar to the existing idle=
parameter already present for the x86 and ppc architectures.

It is also useful on platforms where the WFI instruction misbehaves,
such as Apple Silicon SoCs. Generally, a misbehaving instruction should
be treated as an erratum and patched using the alternatives framework.
However, in the Apple Silicon case we need more flexibility because it is
difficult to detect whether the erratum applies. For example, Linux VMs
inside macOS have the same MIDR and may even seem like they're running
in EL2 in the case of NV, but should continue using WFI (it's trapped and
handled correctly by the hypervisor there). Thus, we prefer to
let the m1n1 bootloader add the idle=nop parameter[1].

Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
---
Changes in v2:
- Applied suggestions by Anshuman Khandual (Thanks!)
- Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
---
 Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
 arch/arm64/kernel/idle.c                        | 30 +++++++++++++++++++++++--
 arch/arm64/kernel/idle.h                        | 13 +++++++++++
 arch/arm64/lib/delay.c                          |  5 ++++-
 4 files changed, 68 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b2d7d3540ded..d7f5471edf8f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2239,6 +2239,29 @@ Kernel parameters
 
 			idle=nomwait: Disable mwait for CPU C-states
 
+			[ARM64,EARLY]
+			Format: idle=wfi, idle=yield, idle=nop
+
+			idle=wfi: Use the WFI (Wait For Interrupt) hint
+			instruction in the idle loop. This is the default and
+			allows the CPU to enter a low-power state until an
+			interrupt arrives.
+
+			idle=yield: Use the YIELD hint instruction instead of
+			WFI. CPUs supporting simultaneous multi-threading (SMT),
+			can continue executing another thread when the current
+			thread reaches the idle loop. This will make the CPUs
+			eat more power, but may be useful to get slightly better
+			performance in some applications, since the CPUs will
+			not enter a low-power state.
+
+			idle=nop: Do not execute any idle instruction in the
+			idle loop. This is useful on platforms where WFI
+			misbehaves, leading to system instability or loss of CPU
+			state. This will make the CPUs eat more power, but may
+			give slightly better performance in some applications,
+			since the CPUs will not enter a low-power state.
+
 	idxd.sva=	[HW]
 			Format: <bool>
 			Allow force disabling of Shared Virtual Memory (SVA)
diff --git a/arch/arm64/kernel/idle.c b/arch/arm64/kernel/idle.c
index 05cfb347ec26..f161711a9954 100644
--- a/arch/arm64/kernel/idle.c
+++ b/arch/arm64/kernel/idle.c
@@ -11,6 +11,27 @@
 #include <asm/cpufeature.h>
 #include <asm/sysreg.h>
 
+#include "idle.h"
+
+enum arm64_idle_mode idle = ARM64_IDLE_WFI;
+
+static int __init setup_idle(char *arg)
+{
+	if (!arg)
+		return -1;
+	else if (!strcmp(arg, "wfi"))
+		idle = ARM64_IDLE_WFI;
+	else if (!strcmp(arg, "yield"))
+		idle = ARM64_IDLE_YIELD;
+	else if (!strcmp(arg, "nop"))
+		idle = ARM64_IDLE_NOP;
+	else
+		return -1;
+
+	return 0;
+}
+early_param("idle", setup_idle);
+
 /*
  *	cpu_do_idle()
  *
@@ -26,8 +47,13 @@ void __cpuidle cpu_do_idle(void)
 
 	arm_cpuidle_save_irq_context(&context);
 
-	dsb(sy);
-	wfi();
+	if (likely(idle == ARM64_IDLE_WFI)) {
+		dsb(sy);
+		wfi();
+	} else if (idle == ARM64_IDLE_YIELD) {
+		dsb(sy);
+		asm volatile("yield" ::: "memory");
+	}
 
 	arm_cpuidle_restore_irq_context(&context);
 }
diff --git a/arch/arm64/kernel/idle.h b/arch/arm64/kernel/idle.h
new file mode 100644
index 000000000000..693f981c9a91
--- /dev/null
+++ b/arch/arm64/kernel/idle.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ARM64_KERNEL_IDLE_H
+#define __ARM64_KERNEL_IDLE_H
+
+extern enum arm64_idle_mode idle;
+
+enum arm64_idle_mode {
+	ARM64_IDLE_WFI,
+	ARM64_IDLE_YIELD,
+	ARM64_IDLE_NOP,
+};
+
+#endif
diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
index e278e060e78a..2452990ed37a 100644
--- a/arch/arm64/lib/delay.c
+++ b/arch/arm64/lib/delay.c
@@ -15,6 +15,8 @@
 
 #include <clocksource/arm_arch_timer.h>
 
+#include "../kernel/idle.h"
+
 #define USECS_TO_CYCLES(time_usecs)			\
 	xloops_to_cycles((time_usecs) * 0x10C7UL)
 
@@ -49,7 +51,8 @@ void __delay(unsigned long cycles)
 		 * Start with WFIT. If an interrupt makes us resume
 		 * early, use a WFET loop to complete the delay.
 		 */
-		wfit(end);
+		if (likely(idle == ARM64_IDLE_WFI))
+			wfit(end);
 		while ((__delay_cycles() - start) < cycles)
 			wfet(end);
 	} else 	if (arch_timer_evtstrm_available()) {

---
base-commit: bee763d5f341b99cf472afeb508d4988f62a6ca1
change-id: 20260705-arm64-idle-param-c27fc0e7ea05

Best regards,
--  
Yureka Lilian <yureka@cyberchaos.dev>

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Sudeep Holla]

On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
> Overriding the idle mechanism might be useful for debugging and performance
> testing. Add a cmdline parameter for it, similar to the existing idle=
> parameter already present for the x86 and ppc architectures.
> 
> It is also useful on platforms where the WFI instruction misbehaves,
> such as Apple Silicon SoCs. Generally, a misbehaving instruction should
> be treated as an erratum and patched using the alternatives framework.
> However, in the Apple Silicon case we need more flexibility because it is
> difficult to detect whether the erratum applies. For example, Linux VMs
> inside macOS have the same MIDR and may even seem like they're running
> in EL2 in the case of NV, but should continue using WFI (it's trapped and
> handled correctly by the hypervisor there). Thus, we prefer to
> let the m1n1 bootloader add the idle=nop parameter[1].
> 
> Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
> Suggested-by: Will Deacon <will@kernel.org>
> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
> ---
> Changes in v2:
> - Applied suggestions by Anshuman Khandual (Thanks!)
> - Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
> ---
>  Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
>  arch/arm64/kernel/idle.c                        | 30 +++++++++++++++++++++++--
>  arch/arm64/kernel/idle.h                        | 13 +++++++++++
>  arch/arm64/lib/delay.c                          |  5 ++++-
>  4 files changed, 68 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index b2d7d3540ded..d7f5471edf8f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2239,6 +2239,29 @@ Kernel parameters
>  
>  			idle=nomwait: Disable mwait for CPU C-states
>  
> +			[ARM64,EARLY]
> +			Format: idle=wfi, idle=yield, idle=nop
> +
> +			idle=wfi: Use the WFI (Wait For Interrupt) hint
> +			instruction in the idle loop. This is the default and
> +			allows the CPU to enter a low-power state until an
> +			interrupt arrives.

Just curious as when and why one would need to use idle=wfi if that is the
default behaviour. I am missing the need to have it.

> +
> +			idle=yield: Use the YIELD hint instruction instead of
> +			WFI. CPUs supporting simultaneous multi-threading (SMT),
> +			can continue executing another thread when the current
> +			thread reaches the idle loop. This will make the CPUs
> +			eat more power, but may be useful to get slightly better
> +			performance in some applications, since the CPUs will
> +			not enter a low-power state.
> +
> +			idle=nop: Do not execute any idle instruction in the
> +			idle loop. This is useful on platforms where WFI
> +			misbehaves, leading to system instability or loss of CPU
> +			state. This will make the CPUs eat more power, but may
> +			give slightly better performance in some applications,
> +			since the CPUs will not enter a low-power state.
> +
>  	idxd.sva=	[HW]
>  			Format: <bool>
>  			Allow force disabling of Shared Virtual Memory (SVA)
> diff --git a/arch/arm64/kernel/idle.c b/arch/arm64/kernel/idle.c
> index 05cfb347ec26..f161711a9954 100644
> --- a/arch/arm64/kernel/idle.c
> +++ b/arch/arm64/kernel/idle.c
> @@ -11,6 +11,27 @@
>  #include <asm/cpufeature.h>
>  #include <asm/sysreg.h>
>  
> +#include "idle.h"
> +
> +enum arm64_idle_mode idle = ARM64_IDLE_WFI;
> +
> +static int __init setup_idle(char *arg)
> +{
> +	if (!arg)
> +		return -1;
> +	else if (!strcmp(arg, "wfi"))
> +		idle = ARM64_IDLE_WFI;
> +	else if (!strcmp(arg, "yield"))
> +		idle = ARM64_IDLE_YIELD;
> +	else if (!strcmp(arg, "nop"))
> +		idle = ARM64_IDLE_NOP;
> +	else
> +		return -1;
> +
> +	return 0;
> +}
> +early_param("idle", setup_idle);
> +
>  /*
>   *	cpu_do_idle()
>   *
> @@ -26,8 +47,13 @@ void __cpuidle cpu_do_idle(void)
>  
>  	arm_cpuidle_save_irq_context(&context);
>  
> -	dsb(sy);
> -	wfi();
> +	if (likely(idle == ARM64_IDLE_WFI)) {
> +		dsb(sy);
> +		wfi();
> +	} else if (idle == ARM64_IDLE_YIELD) {
> +		dsb(sy);
> +		asm volatile("yield" ::: "memory");
> +	}
>  
>  	arm_cpuidle_restore_irq_context(&context);


If WFI is replaced by NOP or YIELD, do we really need to save/restore
IRQ context used for pseudo-NMIs which may add some overhead ?

-- 
Regards,
Sudeep

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Will Deacon]

On Mon, Jul 13, 2026 at 10:57:38AM +0100, Sudeep Holla wrote:
> On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
> > Overriding the idle mechanism might be useful for debugging and performance
> > testing. Add a cmdline parameter for it, similar to the existing idle=
> > parameter already present for the x86 and ppc architectures.
> > 
> > It is also useful on platforms where the WFI instruction misbehaves,
> > such as Apple Silicon SoCs. Generally, a misbehaving instruction should
> > be treated as an erratum and patched using the alternatives framework.
> > However, in the Apple Silicon case we need more flexibility because it is
> > difficult to detect whether the erratum applies. For example, Linux VMs
> > inside macOS have the same MIDR and may even seem like they're running
> > in EL2 in the case of NV, but should continue using WFI (it's trapped and
> > handled correctly by the hypervisor there). Thus, we prefer to
> > let the m1n1 bootloader add the idle=nop parameter[1].
> > 
> > Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
> > Suggested-by: Will Deacon <will@kernel.org>
> > Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
> > ---
> > Changes in v2:
> > - Applied suggestions by Anshuman Khandual (Thanks!)
> > - Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
> >  arch/arm64/kernel/idle.c                        | 30 +++++++++++++++++++++++--
> >  arch/arm64/kernel/idle.h                        | 13 +++++++++++
> >  arch/arm64/lib/delay.c                          |  5 ++++-
> >  4 files changed, 68 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index b2d7d3540ded..d7f5471edf8f 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2239,6 +2239,29 @@ Kernel parameters
> >  
> >  			idle=nomwait: Disable mwait for CPU C-states
> >  
> > +			[ARM64,EARLY]
> > +			Format: idle=wfi, idle=yield, idle=nop
> > +
> > +			idle=wfi: Use the WFI (Wait For Interrupt) hint
> > +			instruction in the idle loop. This is the default and
> > +			allows the CPU to enter a low-power state until an
> > +			interrupt arrives.
> 
> Just curious as when and why one would need to use idle=wfi if that is the
> default behaviour. I am missing the need to have it.

It's probably useful to have so that you can override an idle= option
present earlier in the cmdline. e.g.

	idle=nop idle=wfi

will give you the wfi behaviour, which is handy if the cmdline is
stitched topgether from different sources.

Will

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Anshuman Khandual]

On 13/07/26 3:27 PM, Sudeep Holla wrote:
> On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
>> Overriding the idle mechanism might be useful for debugging and performance
>> testing. Add a cmdline parameter for it, similar to the existing idle=
>> parameter already present for the x86 and ppc architectures.
>>
>> It is also useful on platforms where the WFI instruction misbehaves,
>> such as Apple Silicon SoCs. Generally, a misbehaving instruction should
>> be treated as an erratum and patched using the alternatives framework.
>> However, in the Apple Silicon case we need more flexibility because it is
>> difficult to detect whether the erratum applies. For example, Linux VMs
>> inside macOS have the same MIDR and may even seem like they're running
>> in EL2 in the case of NV, but should continue using WFI (it's trapped and
>> handled correctly by the hypervisor there). Thus, we prefer to
>> let the m1n1 bootloader add the idle=nop parameter[1].
>>
>> Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
>> Suggested-by: Will Deacon <will@kernel.org>
>> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
>> ---
>> Changes in v2:
>> - Applied suggestions by Anshuman Khandual (Thanks!)
>> - Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
>> ---
>>  Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
>>  arch/arm64/kernel/idle.c                        | 30 +++++++++++++++++++++++--
>>  arch/arm64/kernel/idle.h                        | 13 +++++++++++
>>  arch/arm64/lib/delay.c                          |  5 ++++-
>>  4 files changed, 68 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index b2d7d3540ded..d7f5471edf8f 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2239,6 +2239,29 @@ Kernel parameters
>>  
>>  			idle=nomwait: Disable mwait for CPU C-states
>>  
>> +			[ARM64,EARLY]
>> +			Format: idle=wfi, idle=yield, idle=nop
>> +
>> +			idle=wfi: Use the WFI (Wait For Interrupt) hint
>> +			instruction in the idle loop. This is the default and
>> +			allows the CPU to enter a low-power state until an
>> +			interrupt arrives.
> 
> Just curious as when and why one would need to use idle=wfi if that is the
> default behaviour. I am missing the need to have it.

I guess once there is a list to chose options from
in the command line, should not the default option 
be listed there as well ?

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Sudeep Holla]

On Mon, Jul 13, 2026 at 12:59:31PM +0100, Will Deacon wrote:
> On Mon, Jul 13, 2026 at 10:57:38AM +0100, Sudeep Holla wrote:
> > On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
> > > Overriding the idle mechanism might be useful for debugging and performance
> > > testing. Add a cmdline parameter for it, similar to the existing idle=
> > > parameter already present for the x86 and ppc architectures.
> > > 
> > > It is also useful on platforms where the WFI instruction misbehaves,
> > > such as Apple Silicon SoCs. Generally, a misbehaving instruction should
> > > be treated as an erratum and patched using the alternatives framework.
> > > However, in the Apple Silicon case we need more flexibility because it is
> > > difficult to detect whether the erratum applies. For example, Linux VMs
> > > inside macOS have the same MIDR and may even seem like they're running
> > > in EL2 in the case of NV, but should continue using WFI (it's trapped and
> > > handled correctly by the hypervisor there). Thus, we prefer to
> > > let the m1n1 bootloader add the idle=nop parameter[1].
> > > 
> > > Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
> > > Suggested-by: Will Deacon <will@kernel.org>
> > > Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
> > > ---
> > > Changes in v2:
> > > - Applied suggestions by Anshuman Khandual (Thanks!)
> > > - Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
> > > ---
> > >  Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
> > >  arch/arm64/kernel/idle.c                        | 30 +++++++++++++++++++++++--
> > >  arch/arm64/kernel/idle.h                        | 13 +++++++++++
> > >  arch/arm64/lib/delay.c                          |  5 ++++-
> > >  4 files changed, 68 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > index b2d7d3540ded..d7f5471edf8f 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -2239,6 +2239,29 @@ Kernel parameters
> > >  
> > >  			idle=nomwait: Disable mwait for CPU C-states
> > >  
> > > +			[ARM64,EARLY]
> > > +			Format: idle=wfi, idle=yield, idle=nop
> > > +
> > > +			idle=wfi: Use the WFI (Wait For Interrupt) hint
> > > +			instruction in the idle loop. This is the default and
> > > +			allows the CPU to enter a low-power state until an
> > > +			interrupt arrives.
> > 
> > Just curious as when and why one would need to use idle=wfi if that is the
> > default behaviour. I am missing the need to have it.
> 
> It's probably useful to have so that you can override an idle= option
> present earlier in the cmdline. e.g.
> 
> 	idle=nop idle=wfi
> 
> will give you the wfi behaviour, which is handy if the cmdline is
> stitched topgether from different sources.
> 

Thanks, that makes sense.

-- 
Regards,
Sudeep

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Sudeep Holla]

On Mon, Jul 13, 2026 at 05:54:16PM +0530, Anshuman Khandual wrote:
> On 13/07/26 3:27 PM, Sudeep Holla wrote:
> > On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
> >> Overriding the idle mechanism might be useful for debugging and performance
> >> testing. Add a cmdline parameter for it, similar to the existing idle=
> >> parameter already present for the x86 and ppc architectures.
> >>
> >> It is also useful on platforms where the WFI instruction misbehaves,
> >> such as Apple Silicon SoCs. Generally, a misbehaving instruction should
> >> be treated as an erratum and patched using the alternatives framework.
> >> However, in the Apple Silicon case we need more flexibility because it is
> >> difficult to detect whether the erratum applies. For example, Linux VMs
> >> inside macOS have the same MIDR and may even seem like they're running
> >> in EL2 in the case of NV, but should continue using WFI (it's trapped and
> >> handled correctly by the hypervisor there). Thus, we prefer to
> >> let the m1n1 bootloader add the idle=nop parameter[1].
> >>
> >> Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
> >> Suggested-by: Will Deacon <will@kernel.org>
> >> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
> >> ---
> >> Changes in v2:
> >> - Applied suggestions by Anshuman Khandual (Thanks!)
> >> - Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
> >> ---
> >>  Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
> >>  arch/arm64/kernel/idle.c                        | 30 +++++++++++++++++++++++--
> >>  arch/arm64/kernel/idle.h                        | 13 +++++++++++
> >>  arch/arm64/lib/delay.c                          |  5 ++++-
> >>  4 files changed, 68 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index b2d7d3540ded..d7f5471edf8f 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -2239,6 +2239,29 @@ Kernel parameters
> >>  
> >>  			idle=nomwait: Disable mwait for CPU C-states
> >>  
> >> +			[ARM64,EARLY]
> >> +			Format: idle=wfi, idle=yield, idle=nop
> >> +
> >> +			idle=wfi: Use the WFI (Wait For Interrupt) hint
> >> +			instruction in the idle loop. This is the default and
> >> +			allows the CPU to enter a low-power state until an
> >> +			interrupt arrives.
> > 
> > Just curious as when and why one would need to use idle=wfi if that is the
> > default behaviour. I am missing the need to have it.
> 
> I guess once there is a list to chose options from in the command line,
> should not the default option be listed there as well ?
> 

I don't know if it is a requirement or just a practice. But for reasons
Will mentioned, it becomes a requirement.

-- 
Regards,
Sudeep

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Yureka Lilian]

On 7/13/26 11:57, Sudeep Holla wrote:
> On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
>> Overriding the idle mechanism might be useful for debugging and performance
>> testing. Add a cmdline parameter for it, similar to the existing idle=
>> parameter already present for the x86 and ppc architectures.
>>
>> It is also useful on platforms where the WFI instruction misbehaves,
>> such as Apple Silicon SoCs. Generally, a misbehaving instruction should
>> be treated as an erratum and patched using the alternatives framework.
>> However, in the Apple Silicon case we need more flexibility because it is
>> difficult to detect whether the erratum applies. For example, Linux VMs
>> inside macOS have the same MIDR and may even seem like they're running
>> in EL2 in the case of NV, but should continue using WFI (it's trapped and
>> handled correctly by the hypervisor there). Thus, we prefer to
>> let the m1n1 bootloader add the idle=nop parameter[1].
>>
>> Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
>> Suggested-by: Will Deacon <will@kernel.org>
>> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
>> ---
>> Changes in v2:
>> - Applied suggestions by Anshuman Khandual (Thanks!)
>> - Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
>> ---
>>   Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
>>   arch/arm64/kernel/idle.c                        | 30 +++++++++++++++++++++++--
>>   arch/arm64/kernel/idle.h                        | 13 +++++++++++
>>   arch/arm64/lib/delay.c                          |  5 ++++-
>>   4 files changed, 68 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index b2d7d3540ded..d7f5471edf8f 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2239,6 +2239,29 @@ Kernel parameters
>>   
>>   			idle=nomwait: Disable mwait for CPU C-states
>>   
>> +			[ARM64,EARLY]
>> +			Format: idle=wfi, idle=yield, idle=nop
>> +
>> +			idle=wfi: Use the WFI (Wait For Interrupt) hint
>> +			instruction in the idle loop. This is the default and
>> +			allows the CPU to enter a low-power state until an
>> +			interrupt arrives.
> Just curious as when and why one would need to use idle=wfi if that is the
> default behaviour. I am missing the need to have it.
>
>> +
>> +			idle=yield: Use the YIELD hint instruction instead of
>> +			WFI. CPUs supporting simultaneous multi-threading (SMT),
>> +			can continue executing another thread when the current
>> +			thread reaches the idle loop. This will make the CPUs
>> +			eat more power, but may be useful to get slightly better
>> +			performance in some applications, since the CPUs will
>> +			not enter a low-power state.
>> +
>> +			idle=nop: Do not execute any idle instruction in the
>> +			idle loop. This is useful on platforms where WFI
>> +			misbehaves, leading to system instability or loss of CPU
>> +			state. This will make the CPUs eat more power, but may
>> +			give slightly better performance in some applications,
>> +			since the CPUs will not enter a low-power state.
>> +
>>   	idxd.sva=	[HW]
>>   			Format: <bool>
>>   			Allow force disabling of Shared Virtual Memory (SVA)
>> diff --git a/arch/arm64/kernel/idle.c b/arch/arm64/kernel/idle.c
>> index 05cfb347ec26..f161711a9954 100644
>> --- a/arch/arm64/kernel/idle.c
>> +++ b/arch/arm64/kernel/idle.c
>> @@ -11,6 +11,27 @@
>>   #include <asm/cpufeature.h>
>>   #include <asm/sysreg.h>
>>   
>> +#include "idle.h"
>> +
>> +enum arm64_idle_mode idle = ARM64_IDLE_WFI;
>> +
>> +static int __init setup_idle(char *arg)
>> +{
>> +	if (!arg)
>> +		return -1;
>> +	else if (!strcmp(arg, "wfi"))
>> +		idle = ARM64_IDLE_WFI;
>> +	else if (!strcmp(arg, "yield"))
>> +		idle = ARM64_IDLE_YIELD;
>> +	else if (!strcmp(arg, "nop"))
>> +		idle = ARM64_IDLE_NOP;
>> +	else
>> +		return -1;
>> +
>> +	return 0;
>> +}
>> +early_param("idle", setup_idle);
>> +
>>   /*
>>    *	cpu_do_idle()
>>    *
>> @@ -26,8 +47,13 @@ void __cpuidle cpu_do_idle(void)
>>   
>>   	arm_cpuidle_save_irq_context(&context);
>>   
>> -	dsb(sy);
>> -	wfi();
>> +	if (likely(idle == ARM64_IDLE_WFI)) {
>> +		dsb(sy);
>> +		wfi();
>> +	} else if (idle == ARM64_IDLE_YIELD) {
>> +		dsb(sy);
>> +		asm volatile("yield" ::: "memory");
>> +	}
>>   
>>   	arm_cpuidle_restore_irq_context(&context);
>
> If WFI is replaced by NOP or YIELD, do we really need to save/restore
> IRQ context used for pseudo-NMIs which may add some overhead ?

There are optimizations, even in the ARM64_IDLE_WFI case, which could be 
done here, such as checking that an interrupt actually occurred before 
continuing (and repeating the wfi/yield/nop until this is the case). I 
would prefer not to do these optimizations in this patch series, and 
leave it as future work, because I don't understand all the implications 
at this point. Is this acceptable for you?


Thanks,

— Yureka

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Sudeep Holla]

On Wed, Jul 15, 2026 at 03:24:03PM +0200, Yureka Lilian wrote:
> On 7/13/26 11:57, Sudeep Holla wrote:

[...]

> > 
> > If WFI is replaced by NOP or YIELD, do we really need to save/restore
> > IRQ context used for pseudo-NMIs which may add some overhead ?
> 
> There are optimizations, even in the ARM64_IDLE_WFI case, which could be
> done here, such as checking that an interrupt actually occurred before
> continuing (and repeating the wfi/yield/nop until this is the case). I would
> prefer not to do these optimizations in this patch series, and leave it as
> future work, because I don't understand all the implications at this point.
> Is this acceptable for you?
> 

Sure, I am fine with that. Anyways it is left to the maintainers.

-- 
Regards,
Sudeep

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Will Deacon]

On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
> diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
> index e278e060e78a..2452990ed37a 100644
> --- a/arch/arm64/lib/delay.c
> +++ b/arch/arm64/lib/delay.c
> @@ -15,6 +15,8 @@
>  
>  #include <clocksource/arm_arch_timer.h>
>  
> +#include "../kernel/idle.h"
> +
>  #define USECS_TO_CYCLES(time_usecs)			\
>  	xloops_to_cycles((time_usecs) * 0x10C7UL)
>  
> @@ -49,7 +51,8 @@ void __delay(unsigned long cycles)
>  		 * Start with WFIT. If an interrupt makes us resume
>  		 * early, use a WFET loop to complete the delay.
>  		 */
> -		wfit(end);
> +		if (likely(idle == ARM64_IDLE_WFI))
> +			wfit(end);

Rather than scatter the idle implementation check across all users of
WFI*, why not move this into the macro itself? That way, the callers can
all stay like they are but the macro behaves as specified.

Will

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Yureka Lilian]

On 7/22/26 23:43, Will Deacon wrote:
> On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
>> diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
>> index e278e060e78a..2452990ed37a 100644
>> --- a/arch/arm64/lib/delay.c
>> +++ b/arch/arm64/lib/delay.c
>> @@ -15,6 +15,8 @@
>>   
>>   #include <clocksource/arm_arch_timer.h>
>>   
>> +#include "../kernel/idle.h"
>> +
>>   #define USECS_TO_CYCLES(time_usecs)			\
>>   	xloops_to_cycles((time_usecs) * 0x10C7UL)
>>   
>> @@ -49,7 +51,8 @@ void __delay(unsigned long cycles)
>>   		 * Start with WFIT. If an interrupt makes us resume
>>   		 * early, use a WFET loop to complete the delay.
>>   		 */
>> -		wfit(end);
>> +		if (likely(idle == ARM64_IDLE_WFI))
>> +			wfit(end);
> Rather than scatter the idle implementation check across all users of
> WFI*, why not move this into the macro itself? That way, the callers can
> all stay like they are but the macro behaves as specified.
>
> Will

In practise, I could only find the following uses of WFI / WFIT / wfi() 
/ wfit() in arm64 code: 1) the default idle loop and delay() function; 
arguably the only "real" users 2) parking cores after different kinds of 
unexpected situations / crashes.

Just to confirm, you are suggesting to add the conditionals to 
arch/arm64/include/asm/barrier.h, and have wfi() and wfit() macros not 
actually do WFI / WFIT depending on the value of the idle param?

I'm torn about this: We should maybe first discuss what effect idle= 
should have: Should it prevent WFI running anywhere in the kernel when 
idle=nop, OR is its intended use case to change the default arm64 
implementations for idle and delay, while still allowing other parts of 
the kernel to use WFI (for example, for custom cpuidle implementation)? 
I think the existing nohlt parameter, which disables all idle states, is 
more fitting for the first goal, even though it currently does not 
prevent the wfit in the delay function.

For preventing WFI anywhere, I think alternatives patching based on the 
earlyparam would be the most reliable way to achieve that, and second 
most reliable way is putting the conditional in the wfi() / wfit() macros.

But my assumption is that what we want to achieve is actually closer to 
changing only the default idle implementation, while allowing an idle 
state registered at later point to still do its thing (including using 
WFI for this purpose). And for this (and to be more flexible with other 
idle modes e.g. yield), what I proposed in this patch makes more sense, 
and I'm relatively confident it will fulfill the Apple Silicon use case 
without adding many more scattered checks other than these two.
Does this make sense?


Thanks!

— Yureka

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Will Deacon]

Hi Yureka,

On Mon, Jul 27, 2026 at 10:49:57AM +0200, Yureka Lilian wrote:
> On 7/22/26 23:43, Will Deacon wrote:
> > On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
> > > diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
> > > index e278e060e78a..2452990ed37a 100644
> > > --- a/arch/arm64/lib/delay.c
> > > +++ b/arch/arm64/lib/delay.c
> > > @@ -15,6 +15,8 @@
> > >   #include <clocksource/arm_arch_timer.h>
> > > +#include "../kernel/idle.h"
> > > +
> > >   #define USECS_TO_CYCLES(time_usecs)			\
> > >   	xloops_to_cycles((time_usecs) * 0x10C7UL)
> > > @@ -49,7 +51,8 @@ void __delay(unsigned long cycles)
> > >   		 * Start with WFIT. If an interrupt makes us resume
> > >   		 * early, use a WFET loop to complete the delay.
> > >   		 */
> > > -		wfit(end);
> > > +		if (likely(idle == ARM64_IDLE_WFI))
> > > +			wfit(end);
> > Rather than scatter the idle implementation check across all users of
> > WFI*, why not move this into the macro itself? That way, the callers can
> > all stay like they are but the macro behaves as specified.
> 
> In practise, I could only find the following uses of WFI / WFIT / wfi() /
> wfit() in arm64 code: 1) the default idle loop and delay() function;
> arguably the only "real" users 2) parking cores after different kinds of
> unexpected situations / crashes.
> 
> Just to confirm, you are suggesting to add the conditionals to
> arch/arm64/include/asm/barrier.h, and have wfi() and wfit() macros not
> actually do WFI / WFIT depending on the value of the idle param?
> 
> I'm torn about this: We should maybe first discuss what effect idle= should
> have: Should it prevent WFI running anywhere in the kernel when idle=nop, OR
> is its intended use case to change the default arm64 implementations for
> idle and delay, while still allowing other parts of the kernel to use WFI
> (for example, for custom cpuidle implementation)? I think the existing nohlt
> parameter, which disables all idle states, is more fitting for the first
> goal, even though it currently does not prevent the wfit in the delay
> function.

I think nohlt will break the PSCI cpuidle proposal here:

https://lore.kernel.org/all/20260708-efi-psci-v1-0-9efb3abf0e4c@kernel.org/

> For preventing WFI anywhere, I think alternatives patching based on the
> earlyparam would be the most reliable way to achieve that, and second most
> reliable way is putting the conditional in the wfi() / wfit() macros.
> 
> But my assumption is that what we want to achieve is actually closer to
> changing only the default idle implementation, while allowing an idle state
> registered at later point to still do its thing (including using WFI for
> this purpose). And for this (and to be more flexible with other idle modes
> e.g. yield), what I proposed in this patch makes more sense, and I'm
> relatively confident it will fulfill the Apple Silicon use case without
> adding many more scattered checks other than these two.
> Does this make sense?

I keep changing my mind about this patch :/

What do you think about a funny sort of hybrid approach where:

  * We have idle=, but it really only affects the idle loop
  * We have a cpu_errata entry to detect (based on the MIDR) this CPU
    and then avoid patching in the WFIT instructions (i.e. don't detect
    the ARM64_HAS_WFXT capability).

I think that would solve the case for you, as well as giving others finer
grained control over the idle implementation and adding the infrastructure
we need to handle a CPU with broken wfit.

Will

Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Yureka Lilian]

On 7/31/26 18:16, Will Deacon wrote:
> Hi Yureka,
>
> On Mon, Jul 27, 2026 at 10:49:57AM +0200, Yureka Lilian wrote:
>> On 7/22/26 23:43, Will Deacon wrote:
>>> On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
>>>> diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
>>>> index e278e060e78a..2452990ed37a 100644
>>>> --- a/arch/arm64/lib/delay.c
>>>> +++ b/arch/arm64/lib/delay.c
>>>> @@ -15,6 +15,8 @@
>>>>    #include <clocksource/arm_arch_timer.h>
>>>> +#include "../kernel/idle.h"
>>>> +
>>>>    #define USECS_TO_CYCLES(time_usecs)			\
>>>>    	xloops_to_cycles((time_usecs) * 0x10C7UL)
>>>> @@ -49,7 +51,8 @@ void __delay(unsigned long cycles)
>>>>    		 * Start with WFIT. If an interrupt makes us resume
>>>>    		 * early, use a WFET loop to complete the delay.
>>>>    		 */
>>>> -		wfit(end);
>>>> +		if (likely(idle == ARM64_IDLE_WFI))
>>>> +			wfit(end);
>>> Rather than scatter the idle implementation check across all users of
>>> WFI*, why not move this into the macro itself? That way, the callers can
>>> all stay like they are but the macro behaves as specified.
>> In practise, I could only find the following uses of WFI / WFIT / wfi() /
>> wfit() in arm64 code: 1) the default idle loop and delay() function;
>> arguably the only "real" users 2) parking cores after different kinds of
>> unexpected situations / crashes.
>>
>> Just to confirm, you are suggesting to add the conditionals to
>> arch/arm64/include/asm/barrier.h, and have wfi() and wfit() macros not
>> actually do WFI / WFIT depending on the value of the idle param?
>>
>> I'm torn about this: We should maybe first discuss what effect idle= should
>> have: Should it prevent WFI running anywhere in the kernel when idle=nop, OR
>> is its intended use case to change the default arm64 implementations for
>> idle and delay, while still allowing other parts of the kernel to use WFI
>> (for example, for custom cpuidle implementation)? I think the existing nohlt
>> parameter, which disables all idle states, is more fitting for the first
>> goal, even though it currently does not prevent the wfit in the delay
>> function.
> I think nohlt will break the PSCI cpuidle proposal here:
>
> https://lore.kernel.org/all/20260708-efi-psci-v1-0-9efb3abf0e4c@kernel.org/
>
>> For preventing WFI anywhere, I think alternatives patching based on the
>> earlyparam would be the most reliable way to achieve that, and second most
>> reliable way is putting the conditional in the wfi() / wfit() macros.
>>
>> But my assumption is that what we want to achieve is actually closer to
>> changing only the default idle implementation, while allowing an idle state
>> registered at later point to still do its thing (including using WFI for
>> this purpose). And for this (and to be more flexible with other idle modes
>> e.g. yield), what I proposed in this patch makes more sense, and I'm
>> relatively confident it will fulfill the Apple Silicon use case without
>> adding many more scattered checks other than these two.
>> Does this make sense?
> I keep changing my mind about this patch :/
Ultimately I'm happy we found a solution which covers the Apple Silicon 
use case while also not making too much of a mess elsewhere, and I 
appreciate your feedback a lot!
>
> What do you think about a funny sort of hybrid approach where:
>
>    * We have idle=, but it really only affects the idle loop
>    * We have a cpu_errata entry to detect (based on the MIDR) this CPU
>      and then avoid patching in the WFIT instructions (i.e. don't detect
>      the ARM64_HAS_WFXT capability).
>
> I think that would solve the case for you, as well as giving others finer
> grained control over the idle implementation and adding the infrastructure
> we need to handle a CPU with broken wfit.

The idle param portion, if implemented like you say only affecting the 
idle loop, should be rather uncontroversial.

Getting the other part of it (the WFIT in the delay function) right is 
much more difficult, but it also has less of an performance / efficiency 
impact if it's a bit on the conservative side and we can find a good 
solution independently of the idle param.

>
> Will

Thanks,

- Yureka