Previously Serializable::serializeAll called SimObject::
serializeAll. This created an unnecessary dependency. This
change makes Serializable responsible for the generation
of the checkpoint file, and then the SimObjects will
perform the serialization of the object using that file.
With this change serialize.hh contains only functions
related to the (un)serialization of basic types or
objects that inherit from Serializable. As a general
rule, functions related to the (un)serialization of
specific/other types must be defined in the file that
introduces that type.
Change-Id: I9438b799d7e9d4c992a62c7f9d1f15f3f3250a5a
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38740
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
SimObjects keep a static list with all existing
SimObjects. This list is then used to serialize
all objects declared in the system. If these
macros were used then an object would be serialized
more than once, which is not a correct behavior.
Change-Id: Idc4433ec2a23a21ee5ee2b7cc2facfe3dd979859
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46720
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
With this change serialize.hh is no longer responsible
for the (un)serialization of events. As a general rule,
rules to (un)serialize non-basic types should be defined
at the file that introduces that type. Therefore,
(UN)SERIALIZE_EVENT have been moved to eventq.hh.
Globals has a single instance which must be serialized
and unserialized. Instead of having a stray global
variable handled by Serialization, we pass its management
to Root. As a side effect, Globals is assigned its own
files: sim/globals.(cc/hh).
Finally, 'unserializeGlobals()' is removed, so that
Root can fully handle Globals' serialization. This
breaks checkpoint compatibility, so a checkpoint
upgrader is added.
Change-Id: I9c8e57306f83f9cc30ab2b745a4972755191bec4
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43586
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Device memories are used for PCI devices which have their own pools of
backing store memory such as amdgpu device. The check for an address
being in device memory previously did not handle multiple interleaved
memory devices with the same address range. Therefore, the device memory
check would fail if the interleaving masks did not match. This updates
the method to iterate through all device memories that handle the
RequestorID and returns true if any of the device memories contain the
packet address.
Change-Id: I9339d39c1cb54a5b9075c4a122c118fe61dc6fdb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46381
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are special counters in the framebuffer that are tested during
driver initialization. The expected behavior of the counters is to
return the previously read value + 1. There is one (known) counter used
in driver initialization at a fixed BAR address offset.
Change-Id: Id2dbb5fa9365b0a0453b15013c45aa67a2eec190
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46163
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Although the binary ROM blob and MMIO trace will be placed in
gem5-resources later as 'golden' versions, the scripts are added to
provide instructions for power users of Full System amdgpu that may want
to recreate the files themselves or use a GPU other than the Vega10 GPU
currently modeled.
Change-Id: Ica7ef3b9820b30be32a148ce6cf1d2f81dc2adf9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46162
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
The flow for Full System amdgpu is the use KVM to boot linux and begin
loading the driver module. However, the amdgpu module requires reading
the VGA ROM located at 0xc0000 in X86. KVM does not support having a
small 128KiB hole at this location, therefore we take a checkpoint and
switch to a timing CPU to continue loading the drivers before the VGA
ROM is read.
This creates a checkpoint just before the first MMIOs. This is indicated
by three interrupts being sent to the PCI device. After three interrupts
in a row are counted a checkpoint exit event occurs. The interrupt
counter is reset if a non-interrupt PCI read is seen.
Change-Id: I23b320abe81ff6e766cb3f604eca2979339938e5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46161
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The O3CPU, which supports transactional memory (HTM), is using
the inHtmTransactionalState and getHtmCheckpointPtr methods
to check if we are in the middle of a transaction and return
false or a nullptr if that's not the case.
We need to avoid aborting simulation (panic) when those methods are
called in the O3CPU + Checker simulation.
This patch is providing the minimal support to re-enable O3 + Checker
runs and it is not providing HTM support in the CheckerCPU (meaning, we
won't be able to use the Checker in a transactional simulation)
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I7f71d5290c53b0402763d69f137ecaa1208253fb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46624
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This script previously existed entirely within our Jenkins instance.
However, in the interests of transparancy, and allowing users to run the
Nightly tests on their own machines, this script should be added to the
repo. This also allows the community to change the nightly tests without
contacting the Jenkins' administrators.
Change-Id: I6cc3d7597776dbdeb9efb31766d579a2be733d68
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46520
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add stat in o3 model to track the latency of load instructions
(no SWP) between issue and waking up of dependent instructions.
The max latency tracked in the stat histogram is curently
fixed to 299 and should be changed if someone wants to
track more precisely high latency memory acess.
Change-Id: I5973a4aa279bcc388d1a32b706c2e4f5e3f25e75
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46679
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 class was adding some complexity on the python/C++ front:
The Stage2MMU was a child of the ArmTLB and parent of the Stage2TLB
However, it's C++ implementation was solely issuing stage2 table walks
and was not handling the stage2 translation logic in general.
We are removing the class and moving its implemetation structures
within the table walker.
This simplifies the code: the nested Stage2Translation class has
been renamed to Stage2Walk to make its purpose more explicit
The MMU has now a centralized view of all TLBs and Table Walkers in the
system
Change-Id: I8a13a5b793abb7e602e9a05a908e7e0ec3c37247
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45780
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
On configs with renameWidth > dispatchWidth, on receiving
renameWidth number of only squashed instructions:
the dispatch stage will not be able to treat all instructions.
Some squashed instructions will then remain in the 'inst' buffer
after the dispatch stage.
'validInstsFromRename' function don't take into account squashed
instructions, thus the remaining squashed instructions are
not moved to the skid buffer.
The cycle after, the assert in sortInsts will trigger(on debug mode)
because the 'inst' buffer is not empty.
Change-Id: I1a1ed5a7f040041363bd1b2c7bf10c85eb7febaf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46600
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
