This change:
- Makes this function private.
- Adds better documentation describing the usage.
- Changes the 'init' param to 'board_initialized'
This function really doesn't make much sense to set directly by an
stdlib user. It requires knowing whether or not the the board has been
initialized which is an annoying detail and will cause error if set
incorrectly.
The logic of the `init` parameter has been flipped to be
`board_initialized`. This makes it clearer what the parameter is
doing and what it's for.
The documentation for this function has been updated to make it clearer
on how the `board_initialized` parameter should be used correctly.
Change-Id: I567a48df06e6327b38673a2c510065d4334657e2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64832
Reviewed-by: Melissa Jost <mkjost@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
For Statistics the value is returned. E.g.:
```
print(simstats.board.core.some_integer)
> 5
```
For Groups the names of the stats in that group are listed.
E.g.:
```
print(stats.board.core)
> [Group: [some_integer, another_stat, another_group]]
```
Change-Id: I94cea907608fba622f4fc141d5b22ac95d8cde40
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63271
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
The exclusion in .pre-commit-config.yaml covered all files in
src/python/m5/ext. This excludes src/python/m5/exit/pystats, which we
want covered by black. This commit updates .pre-commit-config.yaml to
only exclude src/python/m5/ext/pyfdt.
This change also runs black on these files.
Change-Id: Iecff45ea2a27a37fc0d00b867d41300aad911c7a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63711
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Hi, we are security researchers from the Advanced Research Center at Trellix.
We have began a campaign to patch a widespread bug named CVE-2007-4559.
CVE-2007-4559 is a 15 year old bug in the Python tarfile package. By using
extract() or extractall() on a tarfile object without sanitizing input,
a maliciously crafted .tar file could perform a directory path traversal
attack. We found at least one unsantized extractall() in your codebase
and are providing a patch for you via pull request. The patch essentially
checks to see if all tarfile members will be extracted safely and throws
an exception otherwise. We encourage you to use this patch or your own
solution to secure against CVE-2007-4559.
If you have further questions you may contact us through this
projects lead researcher Kasimir Schulz.
Change-Id: I891ac6652cfbd479aed51d64ef6d4e0fe740e06d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65271
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This changeset replicates some of the multiprocessing module
implementation from the python standard library in gem5. The goal of
this and following changesets is to enable users to use a *single* set
of python scripts to run and analyze a suite of gem5 simulations.
We must reimplement some of the multiprocessing module becaue it is not
flexible enough to allow for customized command line parameter to the
"python" executable (gem5 in our case). To get around this, I extended
the Process and context objects to be gem5 specific.
The next steps is to wrap the Process and Pool types with gem5-specific
versions that will improve their usability for our needs. With this
changeset, these objects are usable, but it will require significant
user effort to reach the goal of running/analyzing many different gem5
simulations.
There are some limitation:
- The pool will only work if the max tasks per child is 1
- The functions that are executed must come from another module
As an example, the following code should work after applying this
change.
test.py:
```python
from gem5.utils.multiprocessing import Process, Pool
from sim import info, run_sim
if __name__ == '__m5_main__' or __name__ == '__main__':
info('main line')
p1 = Process(target=run_sim, args=('bob',))
p2 = Process(target=run_sim, args=('jane',))
p1.start()
p2.start()
p2.join()
p1.join()
with Pool(processes=4, maxtasksperchild=1) as pool:
pool.map(run_sim, range(10))
```
sim.py:
```
import os
def info(title):
print(title)
print('module name:', __name__)
print('parent process:', os.getppid())
print('process id:', os.getpid())
def run_sim(name):
info('function g')
from gem5.prebuilt.demo.x86_demo_board import X86DemoBoard
from gem5.resources.resource import Resource
from gem5.simulate.simulator import Simulator
board = X86DemoBoard()
board.set_kernel_disk_workload(
kernel=Resource("x86-linux-kernel-5.4.49"),
disk_image=Resource("x86-ubuntu-18.04-img"),
)
simulator = Simulator(board=board)
simulator.run(max_ticks=10000000)
```
Change-Id: I4348ebaa75d006949ec96e732f5dc2a5173c6048
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63432
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Since moving `_connect_things` to a pre-init step, the ArmBoard can now
be refactored to set up things in a more logical manner. In particular,
this patch moves activity out of the `_add_disk_to_board` function and
into the `_pre_initialization` function.
Change-Id: I5d40267f28ae87cd483a0396739c09b8b2b46383
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65052
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Through working with the gem5 stdlib there have been instances where
connecting the memory, processor, and cache hierarchy to the board (via
the AbstractBoard's `_connect_things` function) at the point of the
AbstractBoard's construction is problematic as the memory, processor,
and cache hierarchy may require information to connect correctly that is
only known to the AbstractBoard after construction. In particular this
can occur when a Workload contains information needed to configure
correctly.
To resolve this problem the `_connect_things` function has been moved to
run as a pre-initialization step. That is, run immediately before
`m5.instantiate`. This is done in the Simulator module.
This will break cases where a user utilizes the stdlib AbstractBoard but
does not use the stdlib Simulator module. As such, an Exception is
raised in these cases explaining the fix to the user. This is done via a
hack where the boards' `createCCObject` function (inheritted
from SimObject) is overriden with a check to ensure `_connect_things`
has been run. To fix the `_pre_instantiate` function must be executed
prior to `m5.instantiate` in the Python configuration script. Test and
config scripts in the gem5 repo have been updated accordingly.
Change-Id: Ibaef36eb7433ce104b861b1da80fc600f08f715a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65051
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It is possible that the board has more than just a "main" memory. For
instance, the ArmBoard has a boot memory which is separate from the
`get_memory` function.
This moves the `get_mem_ports` function to the board so that the board
can optionally override it.
Change-Id: I05e388cc93e691e9a4fa674023f158af447349f9
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64631
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
It never made much sense to set checkpoint via the Simulator module as
Checkpoints are very tightly coupled with the Workload being run. This
change therefore moves the checkpoint to the set_workload functions.
Setting checkpoints via the Simulator is deprecated and will be removed
in a future release.
Change-Id: I24d2133b38a86423d3553ec888c917c5fe47b93d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64571
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The previous SimPoint warmup length was limited by the gaps between
the starting instruction of one SimPoint and the ending instruction of
the SimPoint before it. This was to prevent duplicate SimPoints, but it
can significantly limit the warmup length.
In this commit, the warmup length limitation will be extended to the
starting instruction of one SimPoint regardless of the gap between
SimPoints.
A SimPoint checkpoint generator is created to help taking checkpoints
for SimPoints and make sure multiple SimPoint checkpoints are taken
when there are multiple SimPoints sharing the same starting instruction
Change-Id: If95f6813e8cbf5c01e41135c1b1bb91ed2e950ad
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64351
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
In python, when you use -c it consumes all subsequent parameters and
appends them to argv. Now, gem5 and python behave the same with -c.
Python:
> python -c "import sys; print(sys.argv)" --hello -j
['-c', '--hello', '-j']
gem5:
> gem5.opt -c "import sys; print(sys.argv)" --hello -j
gem5 Simulator System. https://www.gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 version [DEVELOP-FOR-22.1]
gem5 compiled Oct 17 2022 15:47:46
gem5 started Oct 17 2022 15:53:45
gem5 executing on challenger, pid 4021103
command line: build/ALL/gem5.opt -c 'import sys; print(sys.argv)' --hello -j
['-c', '--hello', '-j']
Change-Id: I53e87712be9523e0583149235c9787c92618f884
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63151
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This change updates the default actions taken when the user doesn't
specify generators for the exit events in the simulator. Rather than
defining default generators, this change makes the generators more
generic and gives a new decorator to mark them as default.
This change then updates the default generators in the simulator and
only makes some of them issue a default warning. For exit events such as
EXIT, the default will no longer print a warning.
Change-Id: I5552f52392f3aea577034ed278a9ff9e8b5b0b01
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64251
Reviewed-by: Zhantong Qiu <ztqiu@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Modeled after the HiFive Unmatched.
For the cache, we inherited from AbstractClassicCacheHierarchy and
AbstractTwoLevelCacheHierarchy to make a PrivateL1PrivateL2 hierarchy
with the same associativity and sizes as the board. However, the L2
Size is kept as a parameter that can be set by the user.
The core is in-order, therefore we inherited from RISC-V MinorCPU and
used the same pipeline parameters as the ARM HPI CPU, except the
decodeToExecuteForwardDelay, which was increased to 2 to avoid a
PMC access fault.
For the processor, we initialized the core with an ID so that we can
return 4 cores in FS mode, which is the same as the real system,
and 1 in SE mode.
For the memory, we just have a single channel DDR4_2400 with a size of
16 GB and starting at 0x80000000.
For the board, we declared a Boolean variable as a parameter to assign
whether it is in FS mode or not. We inherited from KernelDiskWorkload
and SEBinaryWorkload and initialized the components of the board
according to the Boolean. The other parameters are the clock frequency
and the L2 cache size.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1257
Change-Id: Ic2c066bb3a41dc2f42566ce971f9a665542f9771
Co-authored-by: Jasjeet Rangi <jasrangi@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63411
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
While the `runtime` module's `get_runtime_isa` function throws a warning
to remind user's the function is deprecated, this was not always helpful
to a user when setting a processor without a target ISA.
This change adds additional warnings to the SimpleSwitchableProcessor
and the SimpleProcessor. These warnings explain not explicitly setting
the ISA via the processor's constructor is deprecated behavior.
Change-Id: I994ad8355e0d1c3f07374bebe2b59106fb04d212
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63331
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This change adds a new traffic generator module to the standard
library that can read a .cfg file describing the traffic pattern
as a state machine. It wraps around the TrafficGen SimObject.
In addition it adds a method to ComplexGenerator to set the
traffic from outside using python generators like the example
found in configs/dram/sweep.py.
Change-Id: I5989bb900d26091e6e0e85ea63c741441b72069c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62473
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
simpoints-se-checkpoint.py & simpoints-se-restore.py:
These are two example scripts to show how to use SimPoints functions with
the stdlib.
se_binary_workload.py:
Allow se_binary_workload to take in SimPoint Class item and schedule
SimPoint exit events.
exit_event.py:
Added SIMPOINT_BEGIN and MAX_INSTS exit events.
simulator.py:
Added SIMPOINT_BEGIN and MAX_INSTS exit event scheduling functions.
They can schedule exit events before or during the simulation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1259
Change-Id: Iaa07a83de9dddc293b9f1a230aba8e35d4f5af6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63154
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
This commit:
https://gem5-review.googlesource.com/c/public/gem5/+/62471
set `sim_quantum` for any simulation done via the Simulator module.
However, this causes issues when setting exit events at a particular
tick. It resulted in the exit being off by the `sim_quantum` value. This
is required for KVM setups but is undesirable for non-KVM setups. Ergo,
this commit ensures the `sim_quantum` is only set in cases where KVM
cores are included in a simulation.
There are two items of note here:
1. When using the SwitchableProcessor the KVM cores may be switched out
and therefore not accessable via the `get_cores` method. To get round
this we check if the processor is a SwitchableProcessor and run an
additionial check that _any_ of the cores in the SwitchableProcessor
are KVM. This is a big hacky; the Processor API should be changed to
make this easier.
2. This only partially fixes the problem of exit events being off given
a specified tick. This will still occur in the case a
SwitchableProcessor is used containing KVM cores. E.g., non-KVM cores
will still be "off" when KVM cores are switched out. This issue will
be addressed in a later commit.
Change-Id: Id966d76cd1630b6c41c5972fa9423c9e48eafaf6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63051
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By default, caches in classic memory system are assume to be a mostly
inclusive cache with respect to their upstream caches.
Therefore, `writeback_clean` should be `False` by default, which is
consistent with src/mem/cache/Cache.py
Change-Id: I1395690f7f5fafee7fb151906302877ada953861
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62831
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit adds the concept of a "Workload" to the stdlib. Workloads
specify the details needed to run a particular gem5 workload on an
stdlib board. These are specified as part of gem5-resources and loaded
via the `Workload` class though can be specified locally via the
`CustomWorkload` class.
Tests are included in this commit to verify the functionality of these
Workloads.
Change-Id: I8840d281eb01ee4138f01ee499cae96bf7e0579d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62532
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change adds a component for HBM2 stack in the gem5 stdlib.
For HBM2 stack, the atom size is used to interleave across pseudo
channels in a single physical channel or HBMCtrl and the bits
beyond that will be used to interleave across channels/controllers.
Change-Id: I95a279504981a5c000f38c9a6ad0e03484eb258e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61489
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
