gem5
v20.1.0.0
arch
generic
htm.hh
Go to the documentation of this file.
1
/*
2
* Copyright (c) 2020 ARM Limited
3
* All rights reserved
4
*
5
* The license below extends only to copyright in the software and shall
6
* not be construed as granting a license to any other intellectual
7
* property including but not limited to intellectual property relating
8
* to a hardware implementation of the functionality of the software
9
* licensed hereunder. You may use the software subject to the license
10
* terms below provided that you ensure that this notice is replicated
11
* unmodified and in its entirety in all distributions of the software,
12
* modified or unmodified, in source code or in binary form.
13
*
14
* Redistribution and use in source and binary forms, with or without
15
* modification, are permitted provided that the following conditions are
16
* met: redistributions of source code must retain the above copyright
17
* notice, this list of conditions and the following disclaimer;
18
* redistributions in binary form must reproduce the above copyright
19
* notice, this list of conditions and the following disclaimer in the
20
* documentation and/or other materials provided with the distribution;
21
* neither the name of the copyright holders nor the names of its
22
* contributors may be used to endorse or promote products derived from
23
* this software without specific prior written permission.
24
*
25
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
26
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
27
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
28
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
29
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
30
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
31
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
32
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
33
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
34
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
35
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
36
*/
37
38
/*
39
* Gem5 Hardware Transactional Memory (HTM)
40
*
41
* Here we provide a brief note describing HTM support in Gem5 at
42
* a high level.
43
*
44
* HTM is an architectural feature that enables speculative
45
* concurrency in a shared-memory system; groups of instructions known as
46
* transactions are executed as an atomic unit. The system allows that
47
* transactions be executed concurrently but intervenes if a transaction's
48
* atomicity/isolation is jeapordised and takes corrective action. In this
49
* implementation, corrective active explicitely means rolling back a thread's
50
* architectural state and reverting any memory updates to a point just
51
* before the transaction began.
52
*
53
* This HTM implementation relies on--
54
* (1) A checkpointing mechanism for architectural register state.
55
* (2) Buffering speculative memory updates.
56
*
57
* The checkpointing mechanism is architecture dependent. Each ISA leveraging
58
* HTM support must define a class HTMCheckpoint in src/arch/theISA/htm.hh.
59
* Instances of this class live in O3's ThreadState and Atomic's SimpleThread.
60
* It is up to the ISA to populate this instance when executing an instruction
61
* that begins a new transaction.
62
*
63
* The buffering of speculative memory updates is currently implemented in
64
* the MESI_Three_Level Ruby protocol. The core notifies the L0 cache
65
* controller that a new transaction has started and the controller in turn
66
* places itself in transactional state (htmTransactionalState := true).
67
* When operating in transactional state, the usual MESI protocol changes
68
* slightly. Lines loaded or stored are marked as part of a transaction's
69
* read and write set respectively. If there is an invalidation request to
70
* cache line in the read/write set, the transaction is marked as failed.
71
* Similarly, if there is a read request by another core to a speculatively
72
* written cache line, i.e. in the write set, the transaction is marked as
73
* failed. If failed, all subsequent loads and stores from the core are
74
* made benign, i.e. made into NOPS at the cache controller, and responses are
75
* marked to indicate that the transactional state has failed. When the core
76
* receives these marked responses, it generates a HtmFailureFault with the
77
* reason for the transaction failure. Servicing this fault does two things--
78
* (a) Restores the architectural checkpoint
79
* (b) Sends an HTM abort signal to the cache controller
80
*
81
* The restoration includes all registers in the checkpoint as well as the
82
* program counter of the instruction before the transaction started.
83
*
84
* The abort signal is sent to the L0 cache controller and resets the
85
* failed transactional state. It resets the transactional read and write sets
86
* and invalidates any speculatively written cache lines. It also exits
87
* the transactional state so that the MESI protocol operates as usual.
88
*
89
* Alternatively, if the instructions within a transaction complete without
90
* triggering a HtmFailureFault, the transaction can be committed. The core
91
* is responsible for notifying the cache controller that the transaction is
92
* complete and the cache controller makes all speculative writes visible
93
* to the rest of the system and exits the transactional state.
94
*
95
* Notifting the cache controller is done through HtmCmd Requests which are
96
* a subtype of Load Requests.
97
*
98
* Most HTMs allow for a limited number of nested transactions, e.g. a nesting
99
* depth of two would be inside a transaction started within another
100
* transaction. The ExecContext class is extended with
101
* getHtmTransactionalDepth() to return the current depth. For the
102
* TimingSimpleCPU it is straightforward to track this, whereas for
103
* O3DerivCPU it must be tracked in the frontend and commit stages as well as
104
* be corrected on branch mispredictions. This is done in iew_impl.hh.
105
*/
106
107
#ifndef __ARCH_GENERIC_HTM_HH__
108
#define __ARCH_GENERIC_HTM_HH__
109
110
#include <cstdint>
111
#include <memory>
112
113
#include "
mem/htm.hh
"
114
121
class
ThreadContext
;
122
class
BaseHTMCheckpoint
;
123
124
typedef
std::unique_ptr<BaseHTMCheckpoint>
BaseHTMCheckpointPtr
;
125
129
class
BaseHTMCheckpoint
130
{
131
private
:
132
static
uint64_t
globalHtmUid
;
133
uint64_t
localHtmUid
;
134
135
public
:
136
BaseHTMCheckpoint
() :
localHtmUid
(0),
_valid
(false)
137
{
138
reset
();
139
}
140
virtual
~BaseHTMCheckpoint
() {}
141
150
virtual
void
151
save
(
ThreadContext
*tc)
152
{
153
_valid
=
true
;
154
}
155
165
virtual
void
166
restore
(
ThreadContext
*tc,
HtmFailureFaultCause
cause)
167
{
168
reset
();
169
}
170
171
bool
valid
()
const
{
return
_valid
; }
172
176
uint64_t
177
newHtmUid
()
178
{
179
localHtmUid
= ++
globalHtmUid
;
180
return
localHtmUid
;
181
}
182
186
uint64_t
187
getHtmUid
()
const
188
{
189
return
localHtmUid
;
190
}
191
195
void
196
setHtmUid
(uint64_t new_htm_uid)
197
{
198
localHtmUid
= new_htm_uid;
199
}
200
201
protected
:
210
virtual
void
reset
() {
_valid
=
false
; }
211
bool
_valid
;
212
};
213
214
#endif // __ARCH_GENERIC_HTM_HH__
BaseHTMCheckpoint::globalHtmUid
static uint64_t globalHtmUid
Definition:
htm.hh:132
htm.hh
BaseHTMCheckpoint::_valid
bool _valid
Definition:
htm.hh:211
HtmFailureFaultCause
HtmFailureFaultCause
Definition:
htm.hh:44
BaseHTMCheckpoint::setHtmUid
void setHtmUid(uint64_t new_htm_uid)
Sets the current HTM identifier.
Definition:
htm.hh:196
BaseHTMCheckpoint::localHtmUid
uint64_t localHtmUid
Definition:
htm.hh:133
ThreadContext
ThreadContext is the external interface to all thread state for anything outside of the CPU.
Definition:
thread_context.hh:88
BaseHTMCheckpoint::valid
bool valid() const
Definition:
htm.hh:171
BaseHTMCheckpoint
Transactional Memory checkpoint.
Definition:
htm.hh:129
BaseHTMCheckpoint::restore
virtual void restore(ThreadContext *tc, HtmFailureFaultCause cause)
Every ISA implementing HTM support should override the restore method.
Definition:
htm.hh:166
BaseHTMCheckpointPtr
std::unique_ptr< BaseHTMCheckpoint > BaseHTMCheckpointPtr
Definition:
htm.hh:122
BaseHTMCheckpoint::newHtmUid
uint64_t newHtmUid()
Generates a new HTM identifier (used when starting a new transaction)
Definition:
htm.hh:177
BaseHTMCheckpoint::BaseHTMCheckpoint
BaseHTMCheckpoint()
Definition:
htm.hh:136
BaseHTMCheckpoint::reset
virtual void reset()
Resets the checkpoint once a transaction has completed.
Definition:
htm.hh:210
BaseHTMCheckpoint::getHtmUid
uint64_t getHtmUid() const
Returns the current HTM identifier.
Definition:
htm.hh:187
BaseHTMCheckpoint::save
virtual void save(ThreadContext *tc)
Every ISA implementing HTM support should override the save method.
Definition:
htm.hh:151
BaseHTMCheckpoint::~BaseHTMCheckpoint
virtual ~BaseHTMCheckpoint()
Definition:
htm.hh:140
Generated on Wed Sep 30 2020 14:02:00 for gem5 by
doxygen
1.8.17