Architecture overview¶

The activity monitors extension is an optional extension introduced by theARMv8.4 CPU architecture.

The activity monitors unit, implemented in each CPU, provides performancecounters intended for system management use. The AMU extension provides asystem register interface to the counter registers and also supports anoptional external memory-mapped interface.

Version 1 of the Activity Monitors architecture implements a counter groupof four fixed and architecturally defined 64-bit event counters.

• CPU cycle counter: increments at the frequency of the CPU.
• Constant counter: increments at the fixed frequency of the systemclock.
• Instructions retired: increments with every architecturally executedinstruction.
• Memory stall cycles: counts instruction dispatch stall cycles caused bymisses in the last level cache within the clock domain.

When in WFI or WFE these counters do not increment.

The Activity Monitors architecture provides space for up to 16 architectedevent counters. Future versions of the architecture may use this space toimplement additional architected event counters.

Additionally, version 1 implements a counter group of up to 16 auxiliary64-bit event counters.

On cold reset all counters reset to 0.

Basic support¶

The kernel can safely run a mix of CPUs with and without support for theactivity monitors extension. Therefore, when CONFIG_ARM64_AMU_EXTN isselected we unconditionally enable the capability to allow any late CPU(secondary or hotplugged) to detect and use the feature.

When the feature is detected on a CPU, we flag the availability of thefeature but this does not guarantee the correct functionality of thecounters, only the presence of the extension.

Firmware (code running at higher exception levels, e.g. arm-tf) support isneeded to:

• Enable access for lower exception levels (EL2 and EL1) to the AMUregisters.
• Enable the counters. If not enabled these will read as 0.
• Save/restore the counters before/after the CPU is being put/brought upfrom the ‘off’ power state.

When using kernels that have this feature enabled but boot with brokenfirmware the user may experience panics or lockups when accessing thecounter registers. Even if these symptoms are not observed, the valuesreturned by the register reads might not correctly reflect reality. Mostcommonly, the counters will read as 0, indicating that they are notenabled.

If proper support is not provided in firmware it’s best to disableCONFIG_ARM64_AMU_EXTN. To be noted that for security reasons, this does notbypass the setting of AMUSERENR_EL0 to trap accesses from EL0 (userspace) toEL1 (kernel). Therefore, firmware should still ensure accesses to AMU registersare not trapped in EL2/EL3.

The fixed counters of AMUv1 are accessible though the following systemregister definitions:

• SYS_AMEVCNTR0_CORE_EL0
• SYS_AMEVCNTR0_CONST_EL0
• SYS_AMEVCNTR0_INST_RET_EL0
• SYS_AMEVCNTR0_MEM_STALL_EL0

Auxiliary platform specific counters can be accessed usingSYS_AMEVCNTR1_EL0(n), where n is a value between 0 and 15.

Details can be found in: arch/arm64/include/asm/sysreg.h.

Userspace access¶

Currently, access from userspace to the AMU registers is disabled due to:

• Security reasons: they might expose information about code executed insecure mode.
• Purpose: AMU counters are intended for system management use.

Also, the presence of the feature is not visible to userspace.

Virtualization¶

Currently, access from userspace (EL0) and kernelspace (EL1) on the KVMguest side is disabled due to:

• Security reasons: they might expose information about code executedby other guests or the host.

Any attempt to access the AMU registers will result in an UNDEFINEDexception being injected into the guest.