summaryrefslogtreecommitdiff
path: root/src/arch/arm/pmu.cc
AgeCommit message (Collapse)Author
2017-11-21arch-arm: ArmPMU refactorJose Marinho
Change the definition of PMU events in order to integrate events not cannot easily be represented by probe points. The software increment event is now defined as a special type with its separate implementation in pmu.cc and pmu.hh. Change-Id: I43874b9641bf38c54f6ba2c26386542b6a73e282 Signed-off-by: Jose Marinho <jose.marinho@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5764 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2017-11-20arch-arm: Ensure counters keep events on checkpoint resumeJose Marinho
Events were not being attached to counters after a checkpoint resume. By not storing the enable private variable from the stored state the recreation of the event to counter association is automatically carried. The enable state is stored in the reg_pmcnten. Change-Id: I46344df0882a9050c900efb2e8996d64dbfbf297 Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5761 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2017-08-30arch-arm: Only increment SW PMU counters on writes to PMSWINCJose Marinho
When writing a bitmask of counters to PMSWINC, the PMU currently increments the corresponding counters regardless of what they are configured to count. According to the ARM ARM (D5.10.4), counters should only be updated if they have been configured to count software events (event type 0). Change-Id: I5b2bc1fae55faa342b863721c9838342442831a9 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/4285 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
2017-07-10arch-arm: Support PMU evens in the 0x4000-0x4040 rangeJose Marinho
ARMv8.1 added a second architected event range, 0x4000-0x4040. Events in this range are discovered using the high word of PMCEID{0,1}_EL0 Change-Id: I4cd01264230e5da4c841268a7cf3e6bd307c7180 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/3960
2017-05-24arm: Fix incorrect handling of PMEVTYPERx_EL0 in PMUAndreas Sandberg
The PMU model currently doesn't calculate the PMU event counter index correctly for writes to the PMEVTYPER[0-5]_EL0 registers. Fix this obvious mistake. Change-Id: I2913eedddeb98480660e2d63948f6d727adf5ab8 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Sudhanshu Jha <sudhanshu.jha@arm.com> Reviewed-on: https://gem5-review.googlesource.com/3121 Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
2016-04-15arm,dev: remove PMU assertion hit on resetBjoern A. Zeeb
Remve the assertion that we always need to add a delta larger than zero as that does not seem to be true when we hit it in the 'PMU reset cycle counter to zero' case. Committed by Jason Lowe-Power <power.jg@gmail.com>
2015-07-07sim: Refactor the serialization base classAndreas Sandberg
Objects that are can be serialized are supposed to inherit from the Serializable class. This class is meant to provide a unified API for such objects. However, so far it has mainly been used by SimObjects due to some fundamental design limitations. This changeset redesigns to the serialization interface to make it more generic and hide the underlying checkpoint storage. Specifically: * Add a set of APIs to serialize into a subsection of the current object. Previously, objects that needed this functionality would use ad-hoc solutions using nameOut() and section name generation. In the new world, an object that implements the interface has the methods serializeSection() and unserializeSection() that serialize into a named /subsection/ of the current object. Calling serialize() serializes an object into the current section. * Move the name() method from Serializable to SimObject as it is no longer needed for serialization. The fully qualified section name is generated by the main serialization code on the fly as objects serialize sub-objects. * Add a scoped ScopedCheckpointSection helper class. Some objects need to serialize data structures, that are not deriving from Serializable, into subsections. Previously, this was done using nameOut() and manual section name generation. To simplify this, this changeset introduces a ScopedCheckpointSection() helper class. When this class is instantiated, it adds a new /subsection/ and subsequent serialization calls during the lifetime of this helper class happen inside this section (or a subsection in case of nested sections). * The serialize() call is now const which prevents accidental state manipulation during serialization. Objects that rely on modifying state can use the serializeOld() call instead. The default implementation simply calls serialize(). Note: The old-style calls need to be explicitly called using the serializeOld()/serializeSectionOld() style APIs. These are used by default when serializing SimObjects. * Both the input and output checkpoints now use their own named types. This hides underlying checkpoint implementation from objects that need checkpointing and makes it easier to change the underlying checkpoint storage code.
2014-12-23arm: Add support for filtering in the PMUAndreas Sandberg
This patch adds support for filtering events in the PMU. In order to do so, it updates the ISADevice base class to forward an ISA pointer to ISA devices. This enables such devices to access the MiscReg file to determine the current execution level.
2014-11-14arm: Fixes based on UBSan and static analysisAndreas Hansson
Another churn to clean up undefined behaviour, mostly ARM, but some parts also touching the generic part of the code base. Most of the fixes are simply ensuring that proper intialisation. One of the more subtle changes is the return type of the sign-extension, which is changed to uint64_t. This is to avoid shifting negative values (undefined behaviour) in the ISA code.
2014-10-16arm: Add a model of an ARM PMUv3Andreas Sandberg
This class implements a subset of the ARM PMU v3 specification as described in the ARMv8 reference manual. It supports most of the features of the PMU, however the following features are known to be missing: * Event filtering (e.g., from different privilege levels). * Access controls (the PMU currently ignores the execution level). * The chain counter (event no. 0x1E) is unimplemented. The PMU itself does not implement any events, it merely provides an interface for the configuration scripts to hook up probes that drive events. Configuration scripts should call addEventProbe() to configure custom events or high-level methods to configure architected events. The Python implementation of addEventProbe() automatically delays event type registration until after instantiation. In order to support CPU switching and some combined counters (e.g., memory references synthesized from loads and stores), the PMU allows multiple probes per event type. When creating a system that switches between CPU models that share the same PMU, PMU events for all of the CPU models can be registered with the PMU. Kudos to Matt Horsnell for the initial gem5 implementation of the PMU.