On Wed, 25 Feb 2026 at 11:22, Alex Bennée <[email protected]> wrote: > > Peter Maydell <[email protected]> writes: > > 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?
Yes (see Arm ARM section B2.12.2). Note that as "global" implies, this is cross-CPU, not just internal to this one. > - 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. It will both use it internally and also exposes it to userspace (in the sense of providing a hwcap that says "we generate an event stream so you can rely on WFE waking up after a while"). The kernel config symbol is ARM_ARCH_TIMER_EVTSTREAM. For internal use, see for instance arch/arm64/lib/delay.c : if the CPU has event streams but not WFIT/WFET then it will use the event stream to implement the delay. > - An event sent by some IMPLEMENTATION DEFINED mechanism. > > I assume we don't need to care about IMPDEF cases for our current CPU models? Yes, we don't need to worry about this part. -- PMM
