This change consists of two scripts,
- riscv-hello-save-checkpoint.py: runs the first million ticks of the
simulation and save a checkpoint.
- riscv-hello-load-checkpoint.py: loads the above checkpoint, and runs
the rest of the simulation.
This change also adds the two scripts as part of quick tests.
Change-Id: I7bd97ba953fab52f298cbbcf213f2ea5c185cc38
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58829
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The previous version of this requires the user to set the `main-isa` at
runtime, as inplemented via
https://gem5-review.googlesource.com/c/public/gem5/+/55423. In order to
keep this work in-sync with how the multi-protocol approach will work
(see here: https://gem5-review.googlesource.com/c/public/gem5/+/59193),
it's been decided this should be set at compile time. With this we are
keeping the `TARGET_ISA` parameter. If this is set, this is the de
facto "main-isa". The `main-isa` parameter has been removed from the
gem5 command-line.
If the `TARGET_ISA` parameter is not set, but only one ISA is compiled,
then this single ISA is assumed to be the `main-isa` for simulation. If
neither `TARGET_ISA` is set or the binary is compiled to a single ISA,
an exception is thrown when `get_runtime_isa` is called.
At the time of writing this change is moot as the multi-isa work has
yet to be merged into the gem5 develop branch. It exists here:
https://gem5.googlesource.com/public/gem5/+/refs/heads/multi-isa and
will need refactored to work with this patch.
The multi-isa tests have been updated. As we no longer pass the
`main-isa` as a run-time parameter, we remove many tests which validated
this use-case.
Change-Id: If3366212fe1dacbae389efa43d79349deb907537
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59949
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The following weekly tests were failing:
https://jenkins.gem5.org/job/weekly/53
This appears to be due to the "lulesh" tests failing with the docker
container running out of memory. This can be recreated with:
```
git clone -b develop https://gem5.googlesource.com/public/gem5
cd gem5
git clone -b develop https://gem5.googlesource.com/public/gem5-resources
docker pull gcr.io/gem5-test/gcn-gpu:latest
docker build -t hacc-test-weekly gem5-resources/src/gpu/halo-finder
docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w \
$(pwd) --memory="18g" hacc-test-weekly bash -c \
"scons build/GCN3_X86/gem5.opt -j`nproc`"
docker run --rm --volume $(pwd):$(pwd) -w \
"$(pwd)/gem5-resources/src/gpu/lulesh" \
-u $UID:$GID --memory="18g" hacc-test-weekly make
docker run --rm -u $UID:$GID --volume "$(pwd)":"$(pwd)" -w \
"$(pwd)" --memory="18g" \
hacc-test-weekly build/GCN3_X86/gem5.opt configs/example/apu_se.py -n3 \
--mem-size=8GB --reg-alloc-policy=dynamic \
--benchmark-root="$(pwd)/gem5-resources/src/gpu/lulesh/bin" -c lulesh
```
It is currently unknown as to why this process consumes so much memory
or how it can be reduced, but increasing the docker container limit to
24GB for the Weekly tests does appear to fix the issue.
Change-Id: Ifcd65d4ab8bf6a12ddf7a45d61c779e691619072
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60009
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 changes adds a new board to the gem5 stdlib, which is capable
of simulating an ARM based full system. It also adds an example
config script to perform a boot-test using an Ubuntu 18.04 disk
image. A test has been added in the gem5-library-example for the
same.
Change-Id: Ic95ee56084a444c7f1cf21cdcbf40585dcf5274a
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58910
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Add a longer test for the GPU Ruby random tester to the nightly
regression. This test is sized to take approximately 30 minutes
while providing more coverage than the per check-in Ruby random test,
which takes 30 seconds.
Change-Id: I398feb1283b24f801275ba13d6c53d236849f2eb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59272
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
In some cases where we wish to use X86 KVM the 'valid_hosts' field was
set to 'constants.supported_hosts'. This can cause problems as the only
valid host for an X86 KVM test is X86. This patch fixes this.
This fix will likely fix some flakey errors observed in the Nightly
tests.
Change-Id: Id0a906ca6602c0358ae632cce314769807bf6e07
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58970
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 two functions are `get_cpu_types_str_set()` which returns a set of
valid CPUTypes as strings, and `get_cpu_type_from_str()` which will
return a CPUType enum given an input string.
The purpose of these functions is to aid and standardize user input
parameters or environment variables.
Test scripts are updated accordingly.
Change-Id: I7cb9263321fe36bc8a7530edfd0d8e8bbd329e0e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58491
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The main restriction with this design is it results in one ISA target
per board. The ISA is declared per core. To make the design simpler it's
assumed a Processor (a collection of cores) are all of the same ISA. As
each board has one processor, this also means a board is typically tied
to one ISA per simulation.
In order to remain backwards compatible and maintain the standard
library APIs, this patch adds a `--main-isa` parameter which will
determine what `gem5.runtime.get_runtime_isa` returns in cases where
mutliple ISAs are compiled in. When setting the ISA in a simulation (via
the Processor or Cores), the user may, as before, choose not to and, in
this case, the `gem5.runtime.get_runtime_isa` function is used.
The `gem5.runtime.get_runtime_isa` function is an intermediate step
which should be removed in future versions of gem5 (users should specify
precisely what ISA they want via configuration scripts). For this reason
it throws a warning when used and should not be heavily relied upon. It
is deprecated.
Change-Id: Ia76541bfa9a5a4b6b86401309281849b49dc724b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55423
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the test in realview64-simple-atomic-checkpoint.py runs the
default number of checkpoint cycles which is 5. Each of these cycles
takes a long time to run (approximately 5 minutes) which makes this test
take a long time to run to completion. We would get almost all of the
benefit of this test in a fraction of the time if we reduce the number
of iterations down to 3. This still has enough iterations to catch bugs
which would happen in one, a different class of bugs which happen when
checkpointing more than once, and even a third iteration for safety.
Because this test is one of the (if not the) most time consuming test in
the quick tests, reducing its length will significantly improve turn
around time when running all those tests.
That is especially valuable when running the tests multiple times to try
to iterate on a bug, or when sweeping through a series of changes trying
to identify the source of breakages. In cases where we might need to
identify failures which don't effect the end product of a series, ie where
a problem is introduced and then coincidentally fixed in a later change,
this is especially important since every individual change needs to be
checked, not just log(n) of the changes like in a binary search.
Ideally in the future we will also try to figure out why taking and
restoring from checkpoints takes so long so that each iteration of this
test is substantially less expensive. If we do that, we could consider
increasing the iteration count again.
Change-Id: Icfa2a391a4a7457d893f2063fab231d22e572deb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53123
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
