Prior to this patch table walks were always cacheable unless
cacheability was globally disabled by SCTLR.C being 0. Arm allows to
select the memory attributes of table walks via the TCR registers.
For example the TCR.IRGN0 bits:
Inner cacheability attribute for memory associated with translation
table walks using TTBR0_EL1.
IRGN0 Meaning
0b00 Normal memory, Inner Non-cacheable.
0b01 Normal memory, Inner Write-Back Read-Allocate Write-Allocate
Cacheable.
0b10 Normal memory, Inner Write-Through Read-Allocate No
Write-Allocate Cacheable.
0b11 Normal memory, Inner Write-Back Read-Allocate No Write-Allocate
Cacheable.
Note: we check IRGNx bits (Inner Shareable domain) instead of ORGNx
(Outer Shareable domain) since in gem5 we consider everything as
Inner Shareable.
Change-Id: If472c218040029c9d165b056a052f522d48d4a82
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22723
Tested-by: kokoro <noreply+kokoro@google.com>
In addition to the test, "#include base/logging.hh" was added to the
"byteswap.hh". It is is required to compile the header.
Added tests ByteswapTest.swap_byte64, ByteswapTest.swap_byte32,
ByteswapTest.swap_byte16, ByteswapTest.swap_byte, ByteswapTest.htog,
and ByteswapTest.gtoh. The file byteswap.hh is mostly templates.
Added test for BigEndianGuest and LittleEndianGuest namespaces.
Change-Id: I8870a55594ed439fe9e1fb333384f73261d1b1b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22080
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The function intmath.leastSigBit is ambiguous given
its name. It does not return the value of the least
significant bit, or the position of the least significant
set bit, but instead 2 to the power of the position of
the least significant set bit. It has thereby been removed
and the function intmath.isPowerOf2 has been refactored to
not require intmath.leastSigBit.
Change-Id: I22479c666cdd059865b8c73b70b5388f98a4584d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The TarmacParser was assuming 32 bit accesses only.
This was creating a mismatch when parsing a trace with 64 bit
accesses.
E.g.
In
clk IT (18) 002001f4 f8008441 O EL3h_s : STR x1,[x2],#8
clk MW8 00201008:000000201008 00000000_40000401
Only the 32 MSBs were checked (00000000)
Change-Id: I51e803b53efe953edcd9378f6c9481c04932331e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21562
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
An earlier change accidentally left out the actualTC-> prefix in the
getCurrentInstCount method which was supposed to delegate the call to
another thread context. Without that, it just called itself and would
infinitely recurse.
This bug was pointed out in email by Robert Henry.
Change-Id: Ibf1fee6b48ff87790309c6d435bd76fa95c6cab9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22623
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If the number of one of the register types is zero (useful on ARM in
the near future), memset will complain that it's given the length of
the array without multiplying by the size of the array elements. This
is a false positive since the length of the array and the number of
elements are both zero.
To avoid that warning/error and to simplify and update the SimpleThread
class slightly, this change replaces the C style arrays with
std::array.
Change-Id: Ifedd081a1940a578765c4d585e623236008ace67
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22523
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is needed when a CMO triggers an exception (e.g. DataAbort) In that
case the faulting address should be the one encoded in the instruction
rather than the cacheline address:
According to armarm:
If a memory fault that sets FAR_EL1 is generated from a data cache
maintenance or other DC instruction, FAR_EL1[63:0] holds the address
specified in the register argument of the instruction.
Change-Id: I6d0dadbef6e70db57438b01a76c5def3bdd2d974
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22443
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
GICv3 ITS is an optional component of GICv3. The previous behaviour
was for a stub ITS to be created by default, which resulted in a crash
for use cases where a GICv3 with no ITS is required.
This patch removes the instantiation of the ITS by default and adds
checks for its presence both in initialization and device tree
generation code.
Change-Id: Id424924c8c1152d512aaa2837de4aa60329ec234
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22423
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The type of the local unique_ptr variable was different from the return type.
In C++11 because of such difference, a copy-ellision would not be possible,
and that required the use of a std::move.
In C++14 the restriction of same types being required was removed, so
std::move would not be needed anymore.
With the addition of the -Wredundant-move warning in newer compilers, having
the std::move on the return became an issue, breaking compilation.
Change-Id: I45d18dfc500bb5db5fe360814feb91853c735a19
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22403
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
This lets us avoid having to set up bridges for all the different
interrupt signals coming out of the CPU. When we have more cores, like
in the x2, x3, and x4 versions of the CPU, we won't have to have a
set of bridges for each set of signals, and can connect them all to
external ports using array notation, keeping everything simple,
concise, and maintainable.
Change-Id: I1a5f707073868516e93c106dc17d105409de668a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21504
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch was created by Bihn Pham during his internship at AMD.
This patch fixes a very significant performance bug when using the O3
CPU model and Ruby. The issue was Ruby returned false when it received
a request to the same address that already has an outstanding request or
when the memory is blocked. As a result, O3 unnecessary squashed the
pipeline and re-executed instructions. This fix merges readRequestTable
and writeRequestTable in Sequencer into a single request table that
keeps track of all requests and allows multiple outstanding requests to
the same address. This prevents O3 from squashing the pipeline.
Change-Id: If934d57b4736861e342de0ab18be4feec464273d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21219
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
