bb45503c5f96c2c1ac0229607adb53047ffeb082
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Gabe Black
|
c498d8bced |
cpu: Specialize CPUs for an ISA at the leaves, not BaseCPU.
The BaseCPU type had been specializing itself based on the value of TARGET_ISA, which is not compatible with building more than one ISA at a time. This change refactors the CPU models so that the BaseCPU is more general, and the ISA specific components are added to the CPU when the CPU types are fully specialized. For instance, The AtomicSimpleCPU has a version called X86AtomicSimpleCPU which installs the X86 specific aspects of the CPU. This specialization is done in three ways. 1. The mmu parameter is assigned an instance of the architecture specific MMU type. This provides a reasonable default, but also avoids having having to use the ISA specific type when the parameter is created. 2. The ISA specific types are made available as class attributes, and the utility functions (including __init__!) in the BaseCPU class can refer to them to get the types they need to set up the CPU at run time. Because SimObjects have strange, unhelpful semantics as far as assigning to their attributes, these types need to be set up in a non-SimObject class, which is then brought in as a base of the actual SimObject type. Because the metaclass of this other type is just "type", things work like you would expect. The SimObject doesn't do any special processing of base classes if they aren't also SimObjects, so these attributes survive and are accessible using normal lookup in the BaseCPU class. 3. There are some methods like addCheckerCPU and properties like needsTSO which have ISA specific values or behaviors. These are set in the ISA specific subclass, where they are inherently specific to an ISA and don't need to check TARGET_ISA. Also, the DummyChecker which was set up for the BaseSimpleCPU which doesn't actually do anything in either C++ or python was not carried forward. The CPU type still exists, but it isn't installed in the simple CPUs. To provide backward compatibility, each ISA implements a .py file which matches the original .py for a CPU, and the original is renamed with a Base prefix. The ISA specific version creates an alias with the old CPU name which maps to the ISA specific type. This way, old scripts which refer to, for example, AtomicSimpleCPU, will get the X86AtomicSimpleCPU if the x86 version was compiled in, the ArmAtomicSimpleCPU on arm, etc. Unfortunately, because of how tags on PySource and by extension SimObjects are implemented right now, if you set the tags on two SimObjects or PySources which have the same module path, the later will overwrite the former whether or not they both would be included. There are some changes in review which would revamp this and make it work like you would expect, without this central bookkeeping which has the conflict. Since I can't use that here, I fell back to checking TARGET_ISA to decide whether to tell SCons about those files at all. In the long term, this mechanism should be revamped so that these compatibility types are only available if there is exactly one ISA compiled into gem5. After the configs have been updated and no longer assume they can use AtomicSimpleCPU in all cases, then these types can be deleted. Also, because ISAs can now either provide subclasses for a CPU or not, the CPU_MODELS variable has been removed, meaning the non-ISA specialized versions of those CPU models will always be included in gem5, except when building the NULL ISA. In the future, a more granular config mechanism will hopefully be implemented for *all* of gem5 and not just the CPUs, and these can be conditional again in case you only need certain models, and want to reduce build time or binary size by excluding the others. Change-Id: I02fc3f645c551678ede46268bbea9f66c3f6c74b Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52490 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Gabe Black <gabe.black@gmail.com> Tested-by: kokoro <noreply+kokoro@google.com> |
||
|
Timothy Hayes
|
0a8a787de3 |
mem-ruby: HTM mem implementation
This patch augments the MESI_Three_Level Ruby protocol with hardware transactional memory support. The HTM implementation relies on buffering of speculative memory updates. The core notifies the L0 cache controller that a new transaction has started and the controller in turn places itself in transactional state (htmTransactionalState := true). When operating in transactional state, the usual MESI protocol changes slightly. Lines loaded or stored are marked as part of a transaction's read and write set respectively. If there is an invalidation request to cache line in the read/write set, the transaction is marked as failed. Similarly, if there is a read request by another core to a speculatively written cache line, i.e. in the write set, the transaction is marked as failed. If failed, all subsequent loads and stores from the core are made benign, i.e. made into NOPS at the cache controller, and responses are marked to indicate that the transactional state has failed. When the core receives these marked responses, it generates a HtmFailureFault with the reason for the transaction failure. Servicing this fault does two things-- (a) Restores the architectural checkpoint (b) Sends an HTM abort signal to the cache controller The restoration includes all registers in the checkpoint as well as the program counter of the instruction before the transaction started. The abort signal is sent to the L0 cache controller and resets the failed transactional state. It resets the transactional read and write sets and invalidates any speculatively written cache lines. It also exits the transactional state so that the MESI protocol operates as usual. Alternatively, if the instructions within a transaction complete without triggering a HtmFailureFault, the transaction can be committed. The core is responsible for notifying the cache controller that the transaction is complete and the cache controller makes all speculative writes visible to the rest of the system and exits the transactional state. Notifting the cache controller is done through HtmCmd Requests which are a subtype of Load Requests. KUDOS: The code is based on a previous pull request by Pradip Vallathol who developed HTM and TSX support in Gem5 as part of his master’s thesis: http://reviews.gem5.org/r/2308/index.html JIRA: https://gem5.atlassian.net/browse/GEM5-587 Change-Id: Icc328df93363486e923b8bd54f4d77741d8f5650 Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30319 Reviewed-by: Jason Lowe-Power <power.jg@gmail.com> Maintainer: Jason Lowe-Power <power.jg@gmail.com> Tested-by: kokoro <noreply+kokoro@google.com> |