The dmesg level is currently set to 3 which will not display errors if
the amdgpu driver fails to load. Changing to level 8 will show errors in
the gem5 terminal and is not too spammy. This will help GPUFS developers
with bug reports since we would actually be able to observe an error.
Currently if the driver fails to load, there is no way to detect it and
applications will attempt to run, usually failing on getting device
properties.
Change-Id: I56b9581c1a12a8ce329066d18d6a072d006c096d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69977
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Currently, taking a checkpoint with a ruby cache involves moving all
the dirty data in cache to memory. This is done by keeping **only**
simulating the cache until all dirty data are flushed to the memory
before taking the checkpoint.
However, when the cache does not have dirty data, it is a problem if
we keep simulating the cache. E.g., calling checkpoint caused the gem5
"empty event queue" assertion fault when running the ruby cache in
atomic_noncaching mode. Since the mode bypasses the cache, all blocks
are invalid and do not contain dirty data. Subsequently, there is no
event placed to the event queue when we keep **only** simulating the
cache before taking the checkpoint.
This patch fixes this problem by checking if there is any actionable
item when trying to move dirty data to memory. If there is no block
contains dirty data, we simply choose not to continue simulating the
cache before taking the checkpoint.
Change-Id: Idfa09be51274c7fc8a340e9e33167f5b32d1b866
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69897
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The SwitchableProcessors in the standard library have switched-in and
switched-out cores. The `get_cores` API in the stdlib only returns
switched-in cores. In most uses this is desirable.
In the case of setting workloads in SE mode it's necessary to set the
workload to every core, switched-in and switched-out. As the `get_cores`
function was used for this, SwitchableProcessors were failing when used
in SE Mode.
This patch checks the processor type and, if a SwitchableProcessor, uses
the SwitchableProcessor's special `_all_cores` function which gets all
the cores, regardless as to their switched-in/switched-out status.
Issue-on: https://gem5.atlassian.net/browse/GEM5-1320
Change-Id: I0b7a699ac6196e827667955bef7afa37b2648744
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68997
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Removed the calls to `sys.exit()` from the Arm simple configs. These
calls terminate gem5's embedded Python interpreter and gem5 at the end
of the config script, preventing gem5 from dropping into the
interactive IPython shell when the `--interactive` option has been
specified.
Change-Id: I0c350b0d107f297691255361d25c566c889f9469
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69687
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Only the GICv3 model has a `gicv4` parameter, causing the current
`baremetal.py` config to throw an exception when used with the
VExpress_GEM5_V1 platform containing a GICv2.
This patch checks for the existence of the `gicv4` parameter, allowing
all VExpress platforms to be used.
Change-Id: I72667a9caee64fa497bda516217cd424050eb242
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69685
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
gem5 supports Tarmac trace generation for Arm simulations, but there
are no examples of how to use this feature.
This patch adds a `--tarmac-gen` option to three of the simple Arm
configs. Tarmac generation is useful for out-of-the-box users, and
this patch also provides an example of how to use the Tarmac
generation feature.
Change-Id: I0d3c523b5c0bb6d94de93bc502e4451622fb635d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69684
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Converted the generic DPRINTF messages for the GICv2 register reads
and writes (showing only the memory mapped address) to finer grained
DPRINTF messages showing the names of the mapped registers being
accessed.
This change is intended to make it easier to debug the GIC setup from
the gem5 debug trace.
Change-Id: Ic418b2ea8438fed6a5a810ebc0b686cd4c891cb0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69681
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The Tarmac v8 Register ("R") record serialisation formats the
underlying 64-bit storage using a format string field width specifier.
This sets a minimum number of hex characters for the value, rather
than a maximum number of characters.
Because of this, when formatting a narrowed view of a larger
register (e.g. the 32-bit w0 view of the 64-bit x0 register), if any
of the upper bits in the underlying storage are set, then the number
of hex characters used will be the minimum number required to
represent the full value. This could result in irregular formatting,
for example an odd number of hex characters.
This irregular formatting can cause parsing warnings or failures in
some Tarmac tools, for example the Arm Tarmac Trace Utilities [1].
This patch modifies the "R" record formatting to first mask off the
upper bits of the value in the underlying storage to ensure that the
correct number of hex characters are used for the size of the register
being serialised.
[1] https://github.com/ARM-software/tarmac-trace-utilities
Change-Id: Idbd80553d3bcdb56fa9edddd48440ab7d4dff073
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69680
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A flag, introduced in this patch:
https://gem5-review.googlesource.com/c/public/gem5/+/68518
allowed users to pass "no-duplicate-sources" to a gem5 compilation to
not symlink sources in the build directory.
In this patch "src" was added as a shared top-level header directory.
This means that the header files are not copied to the "build" directory
whether or not "no-duplicate-sources" is set.
This patch ensures the "src" directory is only added as a shared
top-level headers directory in the case where "no-duplicate-sources" is
set.
In addition, the "duplicate_sources" parameter (the destination for the
"no-duplicate-sources") was "None" by default, and only set to False
when the flag was used. `default=True` has been added so
"duplicate_sources" can be used as a boolean.
This bug was a cause of a Nightly build error:
https://jenkins.gem5.org/job/nightly/570
In this error, building ext/sst resulted in an error as the Makefile
depends on adding "build/RISCV" to the include path. Without the header
files in the "build" directory, building SST failed. Though, ext/stt
should probably not be using header files in the "build/RISCV"
directory. This will be fixed in another change.
Change-Id: I786486a177fe17a67f3b939c539eecdcbfcaeaf2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69717
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Normally this would just generate a warning, but a warning is easy to
miss, and truncating the path to fit would be surprising. Since the max
length isn't likely to change, a path which has to be truncated is
essentially fundementally wrong, and could be defined as something
else which is short enough before being used in the config.
Note that this only applies to either the abstract path which is just
a string, or the file name and not the directory path on a file based
socket.
Change-Id: I8702cf02c03053b5d0b6133f25b0e588de666f15
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69677
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Earl Ou <shunhsingou@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These can either be set to an integer, in which case it's interpreted
as a TCP port, or a string, in which case it's treated as a unix domain
socket. If the unix domain socket is prefixed with a "@", it will be
treated as an abstract socket.
When stored in the ini file, there is always a prefix added to make
parsing the string more systematic and less ambiguous. A port number is
prefixed with "#", an abstract socket with "@", and a socket file with
the prefix "P" for "path".
Change-Id: I1fc7a579074e849b3becd936238c62fb0d9a2087
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69165
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Use a HostSocket parameter to accept connections, rather than a hand
implementation for unix domain sockets. This consolidates this code
with the code derived from it in ListenSocket, and also makes it
possible to connect to the SharedMemoryServer over an AF_INET socket.
Change-Id: I8e05434d08cffaebdf6c68a967e2ee7613c10a76
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69168
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jui-min Lee <fcrh@google.com>
gem5 officially supports GCC 7+. In GCC 7 the "filesystem" module was
added but only in the "experimental" namespace as
"<experimental/filesystem>". In GCC 8+ the module can be found as
"<filesystem>".
Because of this, include guards to handle this. They include
"<experimental/filesystem>" for the GCC v7 case and the "<filesystem>"
for all other versions.
This bug was partially responsible for this compiler tests failures:
https://jenkins.gem5.org/job/compiler-checks/570
Note: gem5 does not support GCC versions <7. Thus the
"#if __GNUC__ >=8 <GCC 8+ code> #else <GCC 7 code> #endif" logic is
valid.
Change-Id: I31db5488f272f9652edebf24ecefca3722369076
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69598
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
This commit is in response to a failure in the compiler tests:
https://jenkins.gem5.org/job/compiler-checks/570/
GCC versions <9 failed to compile gem5 with the following error:
```
socket.cc:(.text+0x32d5): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
socket.cc:(.text+0x32e5): undefined reference to `std::filesystem::create_directory(std::filesystem::__cxx11::path const&, std::error_code&)'
socket.cc:(.text+0x3370): undefined reference to `std::filesystem::current_path[abi:cxx11](std::error_code&)'
socket.cc:(.text+0x33cc): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
socket.cc:(.text+0x33d7): undefined reference to `std::filesystem::current_path(std::filesystem::__cxx11::path const&, std::error_code&)'
socket.cc:(.text+0x3468): undefined reference to `std::filesystem::current_path(std::filesystem::__cxx11::path const&, std::error_code&)'
```
This was due to this patch:
https://gem5-review.googlesource.com/c/public/gem5/+/69164 which
utilized `std::filesystem`. Prior to to GCC v9, explicit linking with
the stdc++fs library is required due to `std::filesystem` being an
experimental implementation prior to GGC v9.
Change-Id: I584e29f100cb59b40bd155c212e1814f6d8fbb99
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69597
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The "cwd" string is used to store the previous working directory, if
m5term needs to change it to maximize the space it has to create a
unix domain socket using a relative path. That string was not being
freed, which is a small memory leak. This change frees that memory.
Change-Id: I1ad901e7c59614dd938165cae91c3f666d86e872
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69557
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
I modified the spec-2017 benchmark file to include a
processor.switch() statement (which had been removed
in an earlier commit). I also replaced the use of
get_roi_ticks() with get_tick_stopwatch() as this
particular workload is not annotated with "workbegin"
and "workend" annotations.
Lastly, I fixed a minor bug in the spec-2006 file
which printed the total simulated ticks as zero due
to incorrect indexing of get_tick_stopwatch().
Change-Id: If0b6f88d6701a11f32e2e69994582524e0d7097b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69537
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This adds a new scons flag --no-duplicate-sources to build without
linking source files to the build directory.
I find this very helpful when using CLion, since I can now generate a
compilation database using
`bear scons build/ALL/gem5.debug --no-duplicate-sources` and CLion will
now correctly semantically analyze all the files inside src/.
It also ensures that clicking on a build warning/error now opens the
real source file rather than a symlink.
This is not enabled by default since it's possible that certain use
cases are not working correctly, but the basic testing I've done so
far appears to work just fine.
It appears that with this change the `<root>/src` directory is no longer
added to `PYTHONPATH` when running `tests/main.py`, so this change
depends on https://gem5-review.git.corp.google.com/c/public/gem5/+/68757
Change-Id: Iddc9bf9c8211e68e5432c0a07f5c95f427c1ca16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68518
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The call to processor switch from KVM to TIMING was
removed in an earlier commit. This change fixes that.
Also, get_roi_ticks() doesn't work because spec2006
does not have work_begin and work_exit annotations.
This change uses get_tick_stopwatch() to calculate
the roi ticks.
Change-Id: I55efe28ebd686cb4e6c88a528533127fb73c88ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69357
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The GPUFS checkpoint restoration mechanism expects to find a
PM4MapQueues packet in the checkpoint. Since this was not being
checkpointed, the restore phase retrieved a null packet which led to a
segmentation fault. This commit adds PM4MapQueues to the checkpoint and
restores it when deserializing the checkpoint
Change-Id: Ib74a9f36fe89d740a74f94314ada41ecc363abe9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69298
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
These tests were only returning the exit-code of the last command in the
bash script, which would silence failures in commands prior to that.
This patch fixes this. Now these tests will return a non-zero exit code
for any failure when executing these bash scripts.
Change-Id: I2195bbd0357f0b38c192ab5f9e8ad68101786247
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68677
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When running 500.perlbench_r of specint 2017, the system will raise an
assertion error. For function bits of src/base/bitfield.hh (line 76),
the parameter First is smaller than Last. This is caused by incorrect
implementation of uqrshl in src/arch/arm/isa/insts/neon64.isa
When shiftAmt equals 0, which mean uqrshl is actually not shift the
value stored in register. sizeof(Element) * 8 - 1 will be smaller than
sizeof(Element) * 8 - shiftAmt, thus will raise the assertion error.
This commit added this special condition.
No Jira issue has been submitted to report this error
Change-Id: I4162ac3ddb62f162619db400f214f33209b23c19
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69318
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Add DRAMSys as a new AbstractMemorySystem to the gem5 stdlib.
Also, provide convenient subclasses with predefined DRAMSys
configurations.
Add two new stdlib examples:
- dramsys-traffic.py: Demonstrates the usage of DRAMSys
using the stdlib TrafficGenerators
- arm-hello-dramsys.py: A variant of the arm-hello.py
script that uses DRAMSys as it's memory.
These DRAMSys memory components are only compiled into the standard
library if DRAMSys is not compiled into gem5.
Change-Id: I9db87c41fbd9c28bc44e9d6bde13fc225dc16be9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62914
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Make use of get_mem_ports() method of the AbstractMemorySystem
interface when incorporating caches to prevent the usage of the
hard-coded memory port name "port" as some memory controllers do
not have a port with this exact name.
Change-Id: Ic7480166b257c6d356027234758b65b0a97995e3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68482
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
