The backticked (`...`) pip install command in the error messages was
being parsed by the shell script as a command to run when printed. This
fixes the problem by replacing the backticks with single-quotes.
Change-Id: Ib97f6cf9f8bd0eb8bc1beae70efd5277bb51544d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63011
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 way these were set up, there would be a conflict between SimObject
files with the same name set up for different ISAs.
This change creates a single file which tries to determine how many ISAs
are enabled, and if there is exactly one, it creates a backwards
compatible alias for the ISA specific CPU types.
Change-Id: Iab358c2880d49222e814a98354c81d0f306fe1fc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52493
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The TARGET_ISA variable would let you select one ISA from a list of
possible ISAs. That has now been replaced with USE_ARM_ISA, USE_X86_ISA,
etc, variables which are boolean on or off. That will allow any number
of ISAs to be enabled or disabled individually. Enabling something other
than exactly one of these will probably prevent you from getting a
working gem5 binary, but those problems are being addressed in other,
parallel change series.
I decided to use the USE_ prefix since it was consistent with most other
on/off variables we have in gem5. One noteable exception is the
BUILD_GPU setting which, you could convincingly argue, is a better
prefix than USE_. Another option would be to use CONFIG_, in
anticipation of using a kconfig style config mechanism in gem5.
It seemed premature to start using a CONFIG_ prefix here, and if we
decide to switch to some other prefix like BUILD_, it should be a
purposeful choice and not something somebody just starts using.
Change-Id: I90fef2835aa4712782e6c1313fbf564d0ed45538
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52491
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Previously, all components assume the info in arch/riscv/regs/misc.hh to
be the single source of CSR info. That will however make adding
non-standard CSRs difficult as all those CSRs will need to go into the
same header & data structure and might conflict with each other.
In this CL, we add two new functions to the ISA class that provide
information about CSR. The rationale is that, the ISA class is already
the owner of CSR data, so it'll also be in a better position to provide
necessary CSR metadata. With the change, we can create two CPU models
with slightly different custom CSRs easily by creating two derived
RiscvISA classes and overriding the two functions.
We assume that, any customized CSR set is still compatible with standard
CSRs, so we could still utilize the same global map if only standard
CSRs are accessed in the use case.
Note that this does not necessarily mean you cannot or should not add
your customize CSRs into the MiscRegIndex enum. You'll usually still
required to do that to give each CSR an unique id. However, the ability
to override CSRDataMap/CSRMaskMap provide an opportunity to remap how
the CSR index encoded in the instruction maps to CSR, and also give you
a chance to make the read/write logic of certain custom CSRs different.
Change-Id: I168188bdb1baed11cb3e217eb021f289a13bb036
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62891
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Translation entries from regimes with no ASID support are
tagged as global.
For complete translations we cannot simply check for the EL
being EL2 or EL3 as the EL2&0 translation regime does support
ASIDs to differentiate userspace host applications.
We therefore change the LongDescriptor::global method to cover
the EL2&0 case.
We also fix the partial translation logic which was labelling
partial translations as non global without checking for the
translation regime
Change-Id: I9375a34eba6ede97d70ed80e43ce363a57678d55
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62452
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Once the switch node in a dist-gem5 simulation gets started it listens
the first available port starting from the initially supplied one.
To bind full system nodes to the switch, the switch logfile
is parsed for the exact port number.
This is fragile and it broke when the following line:
info: tcp_iface listening on port
changed to
build/ARM/dev/net/tcp_iface.cc:97: info: tcp_iface listening on port
This patch is fixing the problem with a more robust regex matching
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I2721b3c04653ac1e09878e80d8b1ea34ec1a0f73
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62512
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The description explains when we have to set this True (when a
downstream cache acts as a victim cache). Also, it describes general
(default) setup, but this seems inaccurate and not consistent with
default vaule.
Change-Id: I389adb0af0d6421e8a9672c4cf5d23510eb38242
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62832
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>
Theses improvements are:
1. Renames the test suite to the correct "ResourceDownloaderTestSuite".
This was correctly named MD5FileTestSuite due to a copy-and-paste
error.
2. Adds the `setUpClass` and `tearDownClass` from the Python's unittest
framework. These are used to create the simple "resources.json" file
used for testing, set the "GEM5_RESOURCE_JSON", and delete these when
the test is complete.
3. The tests have been updated to utilize the improvements added in 2.
Change-Id: Ia54e45892452bf23b54c8b5a6bb4a94910d83c5f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62651
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>
This change adds a flag to MemCtrl to allow disabling
response port's queue size sanity check. This is needed
for cases/tests where you might want to drive the memory
system with a much higher bandwidth, for example as in
HBM2.
Change-Id: If8d621339ce8f3ab92cbe2b94039486705c64fc1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62372
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
An exception was raised if the SwitchableProcessor was setup to
switch to a KVM core from a non-KVM core (i.e., if KVM cores were
present they needed to be the starting core). This was due to a bug in
the Simulator module where the `root.sim_quantum` as not setup for cases
where the SwitchableProcessor was not starting with a KVM core, thus
causing an error when switched to KVM cores.
This has been fixed by modifying the Simulator module to always set
root.sim_quantum. This is acceptable as this is only used in KVM setups.
Change-Id: If57352ba67b7bca81882eae2ef1e9013ef45272f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62471
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Without setting the correct memory mode the SimpleSwitchableProcessor,
the Minor CPU could not be used as a valid core. This patch corrects
this issue by setting the memory mode to TIMING for Minor CPU cores.
Due to the increasingly complex if-else to determine the memory mode, a
function has been added to CPUTypes to determine what MemMode is
required for each CPUType.
Change-Id: I9384b4a9c0673af34cca04917d763ca45d0ea434
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61535
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The `set_se_binary_workload` function was only setting up the binary to
work on one (the first) processor core. This caused an exception to be
thrown when trying to run an SE mode binary on a multicore system.
Tests have been added to ensure this works as intended.
Note: While this implementation fixes the bugs, it is limited. Future
work is needed to allow for multiprogram workloads.
Change-Id: I33dbaf5015705c299215dc83e8449b16df301cd4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62014
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, when using the switchable processor the first N cores are the
starting cores and the next N cores (e.g., board.processor.core<N+1>)
are the switched in cores. This is confusing when looking at the stats.
This change makes it so that the names of the different processor lists
used in the dictionary when constructing the switchable processor are
used in for the member names as well. This will allow users to have
names like board.processor.ff_cores and board.processor.detailed_cores.
A bit of refactoring of the base processor was required for this.
Change-Id: I244ee5f6080599acb60a777da979da048cf7463e
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62652
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
This patch does two things:
1. Ensures that both the 'pre-commit' and 'commit-msg' hooks are
installed. The `pre-commit install` by itself will only install the
'pre-commit' hooks. This expanded instlal command will also install
the 'commit-msg' hook.
2. How to run pre-commit to automatically format your code.
Change-Id: I0561f2918568bb9191e4ec457c297fcd264248c0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62573
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The gem5 commit msg checker must be run during the 'commit-msg'
stage ergo this is explicitly set. The other hooks are only applicable
to the "commit" stage, the `default_stage` for the hooks.
To install all the hooks, you need to run the following:
```
pre-commit install -t pre-commit -t commit-msg
```
This ensures both the 'commit-msg' and 'pre-commit' hooks are installed.
If you run just `pre-commit install`, only the pre-commit hooks are
installed.
Change-Id: I4a0dcc7159ed5048baa120adf80bbf65f63c11dd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62552
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
