Re: [PATCH v2] arm64: errata: Handle Apple WFI State Loss

On Wed, Jun 17, 2026 at 09:23:03PM +0200, Yureka Lilian wrote:
> On 6/15/26 17:02, Will Deacon wrote:
> > On Mon, Jun 15, 2026 at 02:21:36PM +0200, Yureka Lilian wrote:
> > > Apple Silicon CPUs can lose register state in WFI, leading to crashes
> > > in the idle loop early in the boot process.
> > > This applies to any previous Apple Silicon CPUs too, but is worked
> > > around by configuring the WFI mode in SYS_IMP_APL_CYC_OVRD sysreg
> > > during m1n1's chickens setup.
> > > This workaround no longer exists since M4.

Are we *certain* that there's no equivalent control elsewhere? i.e. this
hasn't just moved?

> > > Add a workaround capability for replacing wfi and wfit with nop, and
> > > an erratum to enable it on the affected CPUs if the workaround using the
> > > sysreg is not already applied. Leave the decision whether the sysreg
> > > workaround can be used up to the earlier parts of the boot chain which
> > > already configure the Apple Silicon chicken bits.
> > > 
> > > This alternative has to be applied in early boot, since otherwise some
> > > cores might enter the idle loop before apply_alternatives_all() is run.
> > > 
> > > Reviewed-by: Sasha Finkelstein <[email protected]>
> > > Signed-off-by: Yureka Lilian <[email protected]>
> > > ---
> > > Changes since v1:
> > > Restricted the erratum to EL2 only, since in EL1 we'd expect the
> > > hypervisor to trap WFI and handle the erratum.

The KVM portion doesn't seem to be implemented in this patch, so we
can't rely on that as-is.

[...]

> > >   #define wfe()		asm volatile("wfe" : : : "memory")
> > >   #define wfet(val)	asm volatile("msr s0_3_c1_c0_0, %0"	\
> > >   				     : : "r" (val) : "memory")
> > > -#define wfi()		asm volatile("wfi" : : : "memory")
> > > -#define wfit(val)	asm volatile("msr s0_3_c1_c0_1, %0"	\
> > > -				     : : "r" (val) : "memory")
> > > +#define wfi()							\
> > > +	do {							\
> > > +		asm volatile(					\
> > > +		ALTERNATIVE("wfi",				\
> > > +			    "nop",				\
> > > +			    ARM64_WORKAROUND_WFI_STATE)		\
> > > +		: : : "memory");				\
> > > +	} while (0)
> > > +#define wfit(val)						\
> > > +	do {							\
> > > +		asm volatile(					\
> > > +		ALTERNATIVE("msr s0_3_c1_c0_1, %0",		\
> > > +			    "nop",				\
> > > +			    ARM64_WORKAROUND_WFI_STATE)		\
> > > +		: : "r" (val) : "memory");			\
> > > +	} while (0)
> > How can you guarantee that we don't run one of these prior to patching?
> 
> We can't, but there are a few points to our advantage, namely the boot cpu
> isn't actually affected by this (when the CYC_OVRD bits are not configured
> or not supported), and first round of patching happens quite early before
> the other cpus are started.

I think you're saying that:

* On the boot CPU, WFI *never* loses register state.

* On other CPUs, WFI *might* lose register state (and this cannot be
  inhibited).

Is that understanding correct, or are there other conditions where a WFI
on the boot CPU can lose register state?

IIRC kdump doesn't ensure the new kernel is started on the boot CPU, so
I think that would be broken. I guess you can't kexec generally due to a
lack of offlining of secondary CPUs.

Mark.