Use that instead of the zero register. This avoids two assumptions,
first that there is a zero register in the first place, and second that
the zero register is an integer.
It also avoids referring to the IntRegClass in non-ISA specific code.
It's very likely that all ISAs will have integer registers, but we
should not build in assumptions about what types of registers an ISA has
in general. For instance, not all ISAs have vector predicate registers,
or a scalar floating point register file.
Change-Id: I730fec90f42b90b5be7e1baddf896e18c53e8510
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49711
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Currently, if you try to instantiate an abstract SimObject the error is
confusing and unhelpful.
"TypeError: _m5.param_<type>.<type>Params: No constructor defined!"
Now, it will instead say "Cannot instantiate an abstract SimObject"
and include the name of the object that causes the error.
Change-Id: Ia8c51e29dccd999ec90dcd39710cc91d9a5fb86f
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59049
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Found via a failing weekly test:
https://jenkins.gem5.org/job/weekly/46/
The following exception was thrown:
```
FileExistsError: [Errno 17] File exists: '/nobackup/jenkins/workspace/weekly/tests/gem5/resources'
At:
/usr/lib/python3.8/os.py(228): makedirs
build/GCN3_X86/python/gem5/resources/resource.py(156): __init__
/nobackup/jenkins/workspace/weekly/tests/gem5/configs/x86_boot_exit_run.py(192): <module>
build/GCN3_X86/python/m5/main.py(440): main
```
It was found that, in cases where the resource directory does not exist,
there is a race condition between gem5 threads to create the directory.
This patch fixes this so threads that lose this race continue normally.
Change-Id: Ie3323c4df0b247e7830c5d3ab93a4d7f9224fe36
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59090
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
How to reset a model correctly is very different between models. Take
cpu models for instance, they have different reset pins for different
parts(typically one for each core, one for shared component, one for
debug interface). To make users more easily to reset the model, here we
want to introduce a special reset port. By implementing the port, users
can simply request a whole reset to the model. If users want to do
partial resets, users still can access the raw pins to achieve what they
want.
Change-Id: I746121d16441e021dc3392aeae1a6d9fa33d637a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58810
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Even though the default value for the license count is 1, it seems that
if fast model is disabled, kconfig will set it to 0. When creating a
cycle using itertools over a list with zero elements, it will raise a
StopIteration.
Even though we don't actually try to build any fast model components
in that case, we do still set them up with a license slot. If the
cycle iterator is essentially broken, that will prevent that from
working and break the build.
This change forces the license count to be at least 1, even if fast
model is disabled and the license count may be set to 0 in the config.
Change-Id: Ia8df256a8f292deb6fb6fa3c5f9a7d58c2b7f782
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58490
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add logic to collect pointers to all GPU TLBs in full system. Implement
the invalid TLBs PM4 packet. The invalidate is done functionally since
there is really no benefit to simulate it with timing and there is no
support in the TLB to do so. This allow application with much larger
data sets which may reuse device memory pages to work in gem5 without
possibly crashing due to a stale translation being leftover in the TLB.
Change-Id: Ia30cce02154d482d8f75b2280409abb8f8375c24
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58470
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The downloader briefly caches the resources.json file in "/tmp". This
works fine if the system only has one user, but in a system supporting
many users, where "/tmp" is shared, there were permission issues when a
user tried to access a resources.json cache from another user. To
resolve this the uid of the user is appended to the filename.
Change-Id: Iba8ab12cd7054c2f5636e444ac0f1f8f73fedc89
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58489
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Requests in GPUFS which go to system memory will not generate the
WriteCompleteResp packets that the VIPER protocol would normally created
for device requests which go through the caches. Therefore, we need to
callback the GM pipe handleResponse to complete the access and make
forward progress.
Change-Id: Ic00c430ce420a591fe5743f758b780d93afd2a38
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57989
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In full system mode, the AMDKernelCode object can reside in either the
system memory or in the dGPU device memory. Currently only reading from
the host/system memory is supported. This adds the necessary code to
read from the dGPU device memory.
Change-Id: I887fc706b3f9834db14e40f36fd29dd3d4602925
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57710
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The emulated driver is currently called in a few locations
unconditionally. This changeset adds checks that we are not in full
system before calling any emulated driver function. In full system the
amdgpu driver running on the disk image handles these functions.
Change-Id: Iea3546b574e29c649351c0fce9154530be89e9b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57712
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The amdgpu driver supports reading and writing scalar and vector memory
addresses that reside in system memory. This is commonly used for things
like blit kernels that perform host-to-device or device-to-host copies
using GPU load/store instructions.
This is done by utilizing the system hub device added in a prior
changeset. Memory packets translated by the Scalar or VMEM TLBs will
have the correspoding system request field set from the PTE in the TLB
which can be used in the compute unit to determine if a request is for
system memory or not.
Another important change is to return global memory tokens for system
requests. Since these do not flow through the GPU coalescer where the
token is returned, the token can be returned once the request is known
to be a system request.
Change-Id: I35030e0b3698f10c63a397f96b81267271e3130e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57711
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@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>
