In PathSearchFunc.__call__(), filename is the name of the file
while filepath contains the relative path to the missing file
relative to $M5_PATH.
Outputing the filepath in the error message makes the error
message more useful as it provides the expected location of
the file as well as the name of the file.
Change-Id: I5f1fdb9e48ac9ae59a26d33331a4a40bc9ff9acd
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45105
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
According to privileged ISA specs, a valid 64 bit virtual address should
have bit 63-39 same as bit 38 (for Sv39). Without this change, kernel page
fault handler does not seem to work correctly. For example, while running
a program, the kernel was segfaulting complaining that it cannot handle
kernel paging request at some virtual address (which is the faulting
address returned by gem5 currently, with all bits after first 39 cleared).
With this change, that error goes away.
Change-Id: Iae7c9d0af19e29214e14a0db08d7c0ac122122bc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45920
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Nils Asmussen <nils.asmussen@barkhauseninstitut.org>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The AMPM paper (https://www.jilp.org/vol13/v13paper3.pdf) defines
the bandwidth-delay calculation as :
Mbandwidth= (Nrequests/Tepoch)×Tlatency
In the code, Tepoch and Tlatency are in ticks (which is okay),
but Tepoch is converted from Cycles (256K) to Ticks using the
clockEdge(Cycle c) function, which is incorrect as it yields currentTick
+ c * clockPeriod() instead of just c * clockPeriod().
In other words, the divider keeps increasing as time advances.
This patch substitutes clockEdge() with cyclesToTicks() to keep
the epoch length (Tepoch) constant throughout simulation.
Change-Id: I69dee29892fa4b9eb8de8715fd72a535e122687f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46479
Reviewed-by: Nathanael Premillieu <nathanael.premillieu@huawei.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This fixes the unlikely but possible following case :
- Assume cond/uncond direct branch A jumping to next branch (PC + 4 in ARM). From
the point of view of the PCState object, the instruction is not branching
(PCState::branching() will return false since it tests whether nextPC != PC + 4 for ARM).
This gets cached in the BTB.
- Assume another cond branch B that is predicted taken but uses the PCState object of the
first branch A from the BTB due to a partial tag match (BTB is not fully tagged).
- At decode, the mistarget will be detected because the target given by the BTB does
not match the target encoded in the instruction B. However, to determine what PC to send to
fetch, decode looks at inst->pcState().branching(), which returns false because the PCState
object has PC X, and nextPC X + 4 (ARM case). Therefore, Decode sends the
fallthrough address of branch B, despite it being predicted taken. If the prediction is
correct, Exec will not realize that the target is wrong since it is the Decode stage's job.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-947
Change-Id: Ia3b960bb660bdfd3c348988d6532735fa3268990
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46260
Reviewed-by: Nathanael Premillieu <nathanael.premillieu@huawei.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
According to the DPC paper : "If the best score is less
than or equal to a fixed value BADSCORE, we turn prefetchoff
during the next phase"
However, the current code will turn prefetch off if the best
*offset* of the learning phase is less than BADSCORE, which
is incorrect.
Change-Id: Ib5790fe1341f2dd6328ec3b018bc52012e376723
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46259
Reviewed-by: Nathanael Premillieu <nathanael.premillieu@huawei.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::Stats became ::statistics.
"statistics" was chosen over "stats" to avoid generating
conflicts with the already existing variables (there are
way too many "stats" in the codebase), which would make
this patch even more disturbing for the users.
Change-Id: If877b12d7dac356f86e3b3d941bf7558a4fd8719
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::ProbePoints became ::probing.
"probing" was chosen over "probe_points" because the
namespace contains more than solely probe points; it
contains all classes related to the act of probing.
Change-Id: I44567974a521707593739a2bd5933391803e5b51
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45412
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::Prefetcher became ::prefetcher.
"prefetch" was chosen over "prefetcher" to avoid generating
conflicts with the already existing variables. "prefetcher"
is a name that is expected to be more common in user's code
than "prefetch".
Change-Id: I8f07217f278a0229e05545b7847f2620ed208c66
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45410
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
The only thing brought in by arch/types.hh is TheISA::PCState. Instead
of having the other types around where they could be used accidentally,
and to make it more obvious what's being exported, this change splits
PCState out into a new switching header called arch/pcstate.hh. The
original arch/types.hh is no longer a switching header, and includes
pcstate.hh.
Change-Id: I8dfd298349e4565f316f7b9a028703289ada6010
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40177
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
If RS1 is X0 or if using an immediate and the value encoded in the RS1
field which is used as the immediate is zero, then the CSR is not
actually written. It doesn't matter whether the register value would
change or not.
Also, if an instruction wants to write to the CSR, the manual does not
say anything about whether or not the register value changes. If a
register is read only, attempting to write it with *any* value should be
illegal.
Change-Id: Ic876eff0fc0c7e25a40ba9213e3c3e49bfa7a33e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45522
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::Compressor became ::compression.
"compression" was chosen over "compressor" to avoid
generating conflicts with the already existing variables,
as well as because the namespace contains more than solely
compressors (e.g., encoders).
Change-Id: I7054845984784b0dffcc4fb90d66c5096a64194d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45406
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These had been templated on a type, and then the width of that type was
considered the amount the PC should advance when executing straight line
code. That type was MachInst, which was loosely the size of an
instruction, but was practically whatever sized data type was fed into
the decoder at a time.
Instead of tying this to a type, this change moves it over to be a
simple number. This avoids a level of indirection, and also further
decouples the type the decoder might use as input from the instruction
size.
Change-Id: I797876a33d27e759c7a6e23a658179201fabfa47
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40176
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
By moving the installation of even the first ThreadContext out of the
constructor, it's possible to construct the stub separately. We can then
move the code that creates the stub out of the base class and into
architecture specific sub-classes.
Change-Id: I0dfd53a3135ebc98ec49acf81d83e58830bc365c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44618
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
There are two user visible effects of this change. First, all of the
threads for a particular workload are moved under a single GDB instance.
The GDB session can see all the threads at once, and can let you move
between them as you want.
Second, since there is a GDB instance per workload and not per CPU, the
wait_for_gdb parameter was moved to the workload.
Change-Id: I510410c3cbb56e445b0fbb1def94c769d3a7b2e3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44617
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
