At this surface it isn't, but in practice it is or wants to be for the following reasons:

- One wants the 'Active' state to be with all the other state of a counter so that it can all be context switched together by a hypervisor, as needed, when context switching a VM.  Having it (and all the other state bits) in mhpmevent means that they are context-switched "for free" when hpmcounter and mhpmevent are saved/restored.  Also, mixing all the 'Active' bits together in a common CSR (like mcountinhibit) complicates context-switching a subset of counters (since one has to explicitly insert and extract the relevant bits from that CSR).

- New/extra OpenSBI calls would be needed to support reading/writing such state that is in other places besides mhpmevent.

- When one brings into the picture setting and clearing the Active bit in response to hardware events (e.g. overflow by another counter or firing of a debug trigger in the Trigger Module), that can't be the current mcountinhibit bits (without changing the definition of that CSR).  In general, one can allow both hardware and software to control the activation and deactivation of active counting by a counter by setting/clearing one common bit that represents the 'active' state of the counter (and in a place that is naturally context-switched along with the rest of the counter state).  (Also, to be clear, this proposal isn't trying to standardize hardware control of Active bits, but it does provide a simple standardized basis for someone wanting to add in their own hardware counter control.)

- mcountinhibit is an M-mode-only CSR.  Any support for lower modes to directly enable/disable counting would require another/new CSR.

The mcounteren, scounteren, and hcounteren CSR's already exist (between the base Privileged spec and the current H-extension draft).  Nothing additional is needed for this counter extension.

Greg