When a user ran "tests/compiler-tests.sh" without passing any arguments,
the compiler tests would fail with:
```
scons: Reading SConscript files ...
Error: No existing build directory and no variant for /gem5
```
However, when passed with arguments, such as:
```
./tests/compiler-tests.sh -j6
```
the tests passed.
The fix for this is to merge the "$build_out" and "$build_args" into a
single string when executing the docker. I do not know exactly why this
works, but it does fix the error.
Change-Id: Ibcd316668b60fb7706f0ee05ab6dadf56228319d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66631
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add tests to test the correctness of replacement policies using
TrafficGen.
Enable debug-flags to print the hit and miss messages so that you
can compare the results with the comments in the tests. Even though
the tests are targeting specific replacement policies, they can be
reused to test all replacement policies.
Change-Id: I3a8013fbcb19adae25b0818ac9e4b0be60be0689
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60389
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This commit adds the following functions to the `m5` python module:
- setMaxTick(tick) -> None
- getMaxTick() -> int
- getTicksUntilMax() -> int
- scheduleTickExitFromCurrent(tick, exit_string) -> None
- scheduleTickExitAbsolute(tick, exit_string) -> None
Until this patch the only way to set an exit at a particular tick was
via `simulate.run` which would reschedule the maximum tick. This
functionality has been explicity exposed via the new `setMaxTick`
function. However, as this is only rescheduling the maximum tick, it
stops scheduling exits at multiple different ticks.
To get around this problem the `scheduleTickExit` functions have been
added. These allow a user to schedule multiple exit events. The
functions contain a `exit_string` parameter that provides the string
the simulator is to return when the specified tick is met. By default
this string is "Tick exit reached" which is used by the stdlib
Simulator module to declare a new `SCHEDULED_TICK` exit event (Note:
this has been deliberatly kept seperate from the `MAX_TICK` exit event.
This commit serves as an attempt to decouple these are two concepts).
Tests are provided in this patch to ensure these new functions work as
intended.
Additional notes:
- The `simulate` function has been fixed to match the documentation. If
the `num_cycles` is -1 then the maximum ticks is set to MaxTicks.
Otherwise the max ticks is set to `curTicks() + num_cycles`. The
functionality of this function will remain unchanged to the end-user.
- Full integration into the Simulator module is not complete as of this
patch. Users must us the m5 python module to set these exit events.
Change-Id: I6c92b31dd409dc866152224600ea8166cfcba38b
Issue-on: https://gem5.atlassian.net/browse/GEM5-1131
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66231
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66331
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
This commit adds the following functions to the `m5` python module:
- setMaxTick(tick) -> None
- getMaxTick() -> int
- getTicksUntilMax() -> int
- scheduleTickExitFromCurrent(tick, exit_string) -> None
- scheduleTickExitAbsolute(tick, exit_string) -> None
Until this patch the only way to set an exit at a particular tick was
via `simulate.run` which would reschedule the maximum tick. This
functionality has been explicity exposed via the new `setMaxTick`
function. However, as this is only rescheduling the maximum tick, it
stops scheduling exits at multiple different ticks.
To get around this problem the `scheduleTickExit` functions have been
added. These allow a user to schedule multiple exit events. The
functions contain a `exit_string` parameter that provides the string
the simulator is to return when the specified tick is met. By default
this string is "Tick exit reached" which is used by the stdlib
Simulator module to declare a new `SCHEDULED_TICK` exit event (Note:
this has been deliberatly kept seperate from the `MAX_TICK` exit event.
This commit serves as an attempt to decouple these are two concepts).
Tests are provided in this patch to ensure these new functions work as
intended.
Additional notes:
- The `simulate` function has been fixed to match the documentation. If
the `num_cycles` is -1 then the maximum ticks is set to MaxTicks.
Otherwise the max ticks is set to `curTicks() + num_cycles`. The
functionality of this function will remain unchanged to the end-user.
- Full integration into the Simulator module is not complete as of this
patch. Users must us the m5 python module to set these exit events.
Change-Id: I6c92b31dd409dc866152224600ea8166cfcba38b
Issue-on: https://gem5.atlassian.net/browse/GEM5-1131
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66231
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
An example case,
```python
mem_side_port = RequestPort(
"This port sends requests and " "receives responses"
)
```
This is the residue of running the python formatter.
This is done by finding all tokens matching the regex `"\s"(?![.;"])`
and manually replacing them by empty strings.
Change-Id: Icf223bbe889e5fa5749a81ef77aa6e721f38b549
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66111
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The "test-gem5-library-example-riscvmatched-fs" test, which runs
"configs/example/gem5_library/riscvmatched-fs.py", was running the
script in full. This takes a very long time. Given we already have boot
tests for RISCV, it's better to just run this configuration to just the
end of the Linux boot (significantly faster than a full OS boot). This
patch adds this feature to the config script and modifies the test to
utilize it.
Change-Id: I1e37a26aab5e9a127ebd64590be79fbc16fe53aa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65853
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65974
The nightly tests failed here:
https://jenkins.gem5.org/job/nightly/430/. What seems to have happened
is the ALL/gem5.opt us compiled within the Docker container but then,
for the KVM tests, there is an attempt to recompile on the host, which
causes compilation problems. The safest strategy here is delete the
build directory prior to running the KVM tests.
In latest versions of our test infrastructure, the KVM tests should be
run completely separately (i.e., in different Jenkin's jobs) to avoid
this.
Change-Id: Id7d18c0504dd324f7a0e5e9a7809463520969dda
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65911
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
The "test-gem5-library-example-riscvmatched-fs" test, which runs
"configs/example/gem5_library/riscvmatched-fs.py", was running the
script in full. This takes a very long time. Given we already have boot
tests for RISCV, it's better to just run this configuration to just the
end of the Linux boot (significantly faster than a full OS boot). This
patch adds this feature to the config script and modifies the test to
utilize it.
Change-Id: I1e37a26aab5e9a127ebd64590be79fbc16fe53aa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65853
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
The ARM Boot Tests required the compilation of ARM/gem5.opt to run a
quick test that the CHI protocol was functioning correctly with ARM and
the ArmBoard. This test has been removed and the test refactored
slightly to use the ALL/gem5.opt.
The CHI protocol is already tested nightly.
Change-Id: Ibe406348caefa2493860036eb89a20681478ea66
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65195
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The `main.py` script will build the ISAs required to run tests. Our
compiler tests (see "tests/compiler-tests.sh") are run nightly and
already test to ensure these ISAs are compiled correctly. Compiling
these ISAs as part of this script is therefore redundant. This patch
removes this step to save testing time.
Change-Id: I58636acfd5512886ac11ca84ee96cbdc9e344c68
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65175
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only tests requiring the the compilation of SPARC, MIPS, and POWER
for the long/nightly suite were
"tests/gem5/multi_isa/test_multi_isa.py" and
"gem5/stdlib/test_requires.py". As compilation of gem5 is quite costly,
it'd best we simply remove these tests. They are minor and not very
important.
Compilation of these ISAs will continue to be tested via the compilation
tests.
Change-Id: I98b33eec5d0adb144109d32851033380f1641ad4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65193
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The long/nightly tests are failing due to timeout (e.g.,:
https://jenkins.gem5.org/job/nightly/398/). We must therefore be more
careful about what we test on a nightly basis.
Each of these X86 boot tests takes an hour and, generally, are largely
the same (just with different CPU cores, cache hierarchy, and memory
system). Given this is largely redundant, some of these tests have been
remove dto save on testing time.
Change-Id: I761fca1aa5e111a03183f83d4e326aaea1bdbc3a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65192
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The long/nightly tests are failing due to timeout (e.g.:
https://jenkins.gem5.org/job/nightly/398/). We must therefore be more
careful about what we test on a nightly basis.
Each of these ARM boot tests takes an hour and, generally, are largely
the same (just with different CPU cores, cache hierarchy, and memory
system). Given this is largely redundant, some of these tests have been
removed to save on testing time.
Change-Id: I8d80d3e0869aca67aa7279a164bdce85d20f3682
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65191
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The "config/example/gem5_library/arm-ubuntu-boot-exit.py" script is
renamed to "config/example/gem5_library/arm-ubuntu-run.py". This makes
it more consistent with similar scripts in the
"config/example/gem5_library" directory: "x86-ubuntu-run.py" and
"riscv-ubuntu-run.py".
Change-Id: I9d96fd68e122f2841573b1717b0969cd44972771
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65132
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
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>
As of https://gem5-review.googlesource.com/c/public/gem5/+/64177 we
support version 22.04. This patch therefore updates the testing
infrastructure (kokoro/quick, nightly/long, weekly/extra-long) to use
the Ubuntu 22.04 docker image.
The "jenkins/gem5art-tests.sh" test script has been updated to no longer
require the `pip upgrade`. This was needed for Ubuntu 20.04 as it
utilized an older version of pip which did not have all the dependencies
these tests requried. As of Ubuntu 20.04 this is no longer required.
Change-Id: Ia8f8b1b2c62ad5d5a8419cb31b6a1d2b6dff7ac9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64291
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
In the case where no regex was specified (i,e., `regex == None`), the
`_iterable_regex` function returned `None`. For the testlib to work this
function must return an iterable.
Without this patch it is not possible to compare two files without a
specifying a regex.
Change-Id: Ibc8a2f783c3b786dbdca6a4284850b594024f2f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64851
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The
'configs/example/gem5_library_checkpoints/simpoints-se-checkpoint.py'
example would dump the savepoint in the CWD. This is fine when running
as an example, but we also run this script as a test. In this case the
checkpoint litters the repository.
To fix this, an optional 'checkpoint-path' argument is added to this
example which specifies where the checkpoint is to be saved. In the
tests, the checkpoint is saved to 'tests/gem5/resources'. This is our
default location for resources needed/produced by tests and is ignored
by git.
Change-Id: I3dccc574b9e64d32386fd822ed7248ee365a0a08
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64092
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
