This makes what are configuration and what are internal SCons variables
explicit and separate, and makes it unnecessary to call out what
variables to export to C++.
These variables will also be plumbed into and out of kconfiglib in later
changes.
Change-Id: Iaf5e098d7404af06285c421dbdf8ef4171b3f001
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56892
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
* The value of build environment variable KVM_ISA is serialized into
the generated file `kvm_isa.hh'. This value should be a string, but on
hosts where the KVM headers are not available, the default `None` is
inserted. Changed the default value to the string `""` in this case.
* Added missing include for `std::array`.
Change-Id: I651122cc46fc9c0757f592b05f4b4cab285cb91f
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57889
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The contextId is generally treated as (and should be) an opaque index
into the System objects threadContext array. When forcing it to
particular values, that introduces gaps in the threadContext array which
trips up other code which is expecting the array to have only valid
entries.
Change-Id: I4997e989b436a3008f65f348722dfb843b2f110a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57089
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
The default constructor for RegId would initialize it with the
IntRegClass and register index 0. This is arbitrary and
indistinguishable from a real ID to the first integer register.
Instead, add a new class type constant InvalidRegClass, and use that to
initialize an otherwise uninitialized RegId.
Also, fill out some enums that needed to handle that value to silence
compiler warnings.
Change-Id: I3b58559f41adc1da5f661121225dbd389230e3af
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49710
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than constantly overwriting the "zero" register to return its
value to zero, just ignore writes to it.
We assume here that the "zero" register is a standard RegVal type
register (ie not bigger than 64 bits) and is accessed as such.
Change-Id: I06029b78103019c668647569c6037ca64a4d9c76
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49709
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The Request::NO_ACCESS flag instructs the cpu model to not issue
the request to the memory port.
While Atomic and Timing CPU models properly implement it [1], [2],
* MinorCPU is not looking at the flag
* O3CPU is looking at the flag only in case of a nested transaction
start/commit
This patch is extending NO_ACCESS support to all memory instructions.
This is achieved by using the localAccess callback in the Request object.
Handling of nested hardware transactions in the O3 LSQUnit is moved within
the local accessor callback
[1]: https://github.com/gem5/gem5/blob/v21.1.0.2/\
src/cpu/simple/timing.cc#L318
[2]: https://github.com/gem5/gem5/blob/v21.1.0.2/\
src/cpu/simple/atomic.cc#L396
Change-Id: Ifd5b388c53ead4fe358aa35d2197c12f1c5bb4f2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56591
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: ZHENGRONG WANG <seanyukigeek@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
If the size of the address range is smaller than the maximum number
of outstanding requests allowed downstream, the tester will get stuck
trying to find a unique address. This patch adds a check for this
condition and forces the tester to wait for responses before
trying to generate another request.
Change-Id: Ie894a074cc4f8c7ad3d875dc21e8eb4f04562d72
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56811
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The tester currently assumes that one token per lane is needed when
checking if an action is ready to be issued. When actually issuing
requests, it is possible that a memory location is not valid for various
reasons. This was not being considered when checking for tokens causing
the tester to acquire more tokens than requests sent. Since tokens are
returned when requests are coalesced, this was causing some tokens never
to be returned, eventually depleting the token pool and causing a
deadlock.
Add a new method which determines the number of tokens needed for an
action. This is called by both the ready check method and the method to
issue the action to ensure they are aligned.
Change-Id: Ic1af72085c3b077539eb3fd129331e776ebdffbc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56450
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Individual register files, like the ones for scalar integer, floating
point, or condition code registers, are now declared as vectors of their
actual type. Accessing them is simple, since the register you want can
be accessed simply by indexing into the vector.
Unfortunately, that means the code that sets up that storage has to know
what that underlying type is, and that means knowing (and hard coding)
information about the ISA being built.
Instead, this change makes the SimpleThread and O3 PhysRegFile classes
store registers as vectors of bytes, and offsets into those vectors
using computed offsets. Because the elements of the register files are
forced to be offset by powers of 2, computing the offsets can be done
with a shift rather than a multiplication.
The accessors which actually pull values in and out of these vectors are
still specific to each register type and need to know what the
underlying type is, but this change pulls that one level out of the CPUs
towards their peripheral APIs. Later changes will factor these uses out
as well.
Change-Id: I5e19d359a0e83e5827ae263d369999f90c7aa63d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49105
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
By default, registers are the size of RegVal, the type often used to
store them. For some types of registers, like vector or vector predicate
registers, the size of each individual register is larger, and can't fit
in a primitive type.
To help facilitate storing even these outliers in a generalized way,
this change adds two fields to RegClassInfo to track the size of
individual registers. One tracks the raw size of the registers
themselves, and the other tracks the minimal shift necessary to find the
offset of a register in a contiguous(ish) array of bytes. By forcing
each register to be aligned to a power of two boundary, we avoid having
to do a multiplication to find their address even if the registers are
oddly sized. We can instead do a shift with a precomputed shift amount
which should be faster.
Change-Id: I035f1b4cb00ece4e8306d7953ea358af75a0d1de
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49104
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The KvmVM will declare itself to the System object, instead of the other
way around. This way the System object can just keep an opaque KvmVM
pointer which does not depend on the KvmVM code even being compiled into
gem5. If there is a KvmVM object, that can more safely assume there is a
corresponding System object to attach itself to.
Also move use of the KvmVM pointer out of constructors, since the VM may
not have registered itself with the System object yet. Those uses can
happen in the init() method instead.
Change-Id: Ia0842612b101315bc1af0232d7f5ae2b55a15922
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56187
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These registers used to be accessed with a two dimensional index, with
one dimension specifying the register, and the second index specifying
the element within that register. This change linearizes that index down
to one dimension, where the elements of each register are laid out one
after the other in sequence.
Change-Id: I41110f57b505679a327108369db61c826d24922e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49148
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
