Peter Maydell <[email protected]> writes:
> On Tue, 24 Feb 2026 at 12:10, Alex Bennée <[email protected]> wrote:
>>
>> This commit extends support for WFI, WFE, WFIT, and WFET instructions
>> for A-profile ARM CPUs, ensuring proper architectural semantics and
>> full ISS (Instruction Specific Syndrome) field support for traps.
>>
>> Key changes:
>> - Update `syn_wfx` in `target/arm/syndrome.h` to include `RN` (register
>> number) and `RV` (register valid) fields using `registerfields.h`
>> macros.
>> - Refactor `HELPER(wfi)` and `HELPER(wfit)` to use correct AArch64
>> syndrome values (CV=0, COND=0xf).
>> - Implement `HELPER(wfet)` and update `trans_WFET` to support the new
>> Wait For Event with Timeout instruction.
>> - Update `HELPER(wfe)` to implement proper A-profile semantics,
>> including trap checks and event register handling.
>> - Extend `event_register` handling to all ARM CPUs (not just M-profile)
>> by updating `HELPER(sev)` and `arm_cpu_has_work`.
>> - Declare WFxT helpers as `TCG_CALL_NO_WG` as they can raise
>> exceptions.
>
> Yeah, no. This all needs to be split out to be anything
> close to reviewable. In particular "report the right
> syndrome info", "make WFE/SEV not NOPs on A profile like
> they are on M-profile" and "do better with WFET" are all
> separate things.
Yeah it was surprising it didn't follow its own plan which did have a
nice breakdown of patches. When I do my human spin I'll make sure it is
split up better.
> Also, this doesn't change any of the places that it needs to
> change to implement the places that architecturally set the
> event register (see R_XRZRK in the Arm ARM),
I was having trouble finding that but searching for just XRZRK finds the
subscript text:
The Event Register for a PE is set by any of the following:
- A Send Event instruction, SEV, executed by any PE in the system.
- A Send Event Local instruction, SEVL, executed by the PE
- An exception return.
These seem easy enough
- The clearing of the global monitor for the PE
Is this the LSTREX monitor?
- An event from a Generic Timer event stream, see Event streams.
So this looks like sub-timer events that trigger events but aren't timer
expiry events? I shall have a look to see if the kernel uses this.
- An event sent by some IMPLEMENTATION DEFINED mechanism.
I assume we don't need to care about IMPDEF cases for our current CPU models?
> so it will
> break code that uses WFE. Notably for A-profile this includes
> generic timer "event streams", which we currently don't implement
> at all.
>
> thanks
> -- PMM
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
