There can only ever be two RLC queues maximum. Use this information for
a simpler data structure to store doorbell information. The patch
changes the std::unordered_map previously used to std::array. This will
also be useful in avoiding erase-while-iterating issues needed to
unregister all queues at once.
Change-Id: I95600e40de51cb1a992a20bcebaf7580ea4d0be8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63172
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Previously framebuffer reads would try reading from MMIO trace, special
addresses, and then anything previously written to a special address
range. This does not handle direct large BAR reads, causing incorrect
results in some applications that were doing this.
Rework the readFramebuffer method to do the following. Remove the MMIO
trace read altogether, as there were not any framebuffer reads from the
trace to begin with. Read special addresses first to avoid overwriting
by previous writes. Next read previous writes to special ranges. The
special range is the GART table. These are required for functional
translations. Lastly read from the device memory directly. This does a
functional read required by the PCIDevice read method which is
non-timing. Reading from device memory is preferred over the map type
used for GART to avoid duplication of a potentially huge amount of data.
With this changeset all but one of the HIP samples and HIP examples
applications now run and pass verification of results.
Change-Id: Id3b788bfc5eaf17cfa1897f25d26f3725d4db321
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63171
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
The virtual and physical address for device memory are typically aligned
to the page size. On the host (x86), however, the physical address may
not be aligned to page size for large page sizes when mixed with 4kB
pages. As a result, the physical address calculation must add, rather
than bitwise-OR, the virtual page offset to the physical page number.
The virtual page offset on the GPU continues to use the variable page
bytes for masking and shifting.
Change-Id: I6563a1eb43d9b59577d32268b8645a7436304bcb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63034
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
The memory management hub ("mmhub") is an aperture that aliases the GPU
device memory. MMHUB addresses functionally map to the same device
address, with the exception that it is guaranteed not to overlap with
host memory. This is useful in gem5 for APIs with Addr type as it
prevents sending e.g., DMAs to the wrong place.
Change-Id: Ia296809a8dc2c5fbdeba6d70cd53215f9ab36c93
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63031
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Support has been added for SDMA RLC queues which are used for host to
device and device to host "memcpy" calls. Previously the SDMA engine was
disabled which caused GPU BLIT kernels to be called. This removes the
environment variable disabling SDMAs which has two main benefits:
- It will be much easier to debug host/device transfer by using SDMA
debug flag.
- Simulation time is improved since we no longer need detailed GPU
simulation to copy data and instead are doing a simple large DMA
Change-Id: I7524245731d301b5c26394318f2156ed6b4c983a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62717
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
In almost all cases reading/writing using the GPU memory manager will
want to wait until that read or write is complete. Therefore, change the
API to not default to no callback so that the user must explicitly
specify nullptr indicating they do not want to wait for completion.
Updates a write call which cannot use a callback due to being atomic in
the base gpu device code.
Change-Id: Id19145d49c7cafc97e2e178819682cb97270a16a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62716
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
If the pre-commit could not be installed the compilation would continue
as the exit code from running the pre-commit install script was not
read or processed. This commit adds a check. If the install is
unsuccessful the users is asked whether they want to continue the
compilation or not.
This check can be ignored with the '--ignore-style'. The tests have been
updated to include this flag in all cases we compile gem5 to ensure
tests remain automated and uninterrupted on Kokoro/Jenkins.
Change-Id: Iaf4db71300883b828b00d77784c9bb46b2698f89
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63012
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
simpoints-se-checkpoint.py & simpoints-se-restore.py:
These are two example scripts to show how to use SimPoints functions with
the stdlib.
se_binary_workload.py:
Allow se_binary_workload to take in SimPoint Class item and schedule
SimPoint exit events.
exit_event.py:
Added SIMPOINT_BEGIN and MAX_INSTS exit events.
simulator.py:
Added SIMPOINT_BEGIN and MAX_INSTS exit event scheduling functions.
They can schedule exit events before or during the simulation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1259
Change-Id: Iaa07a83de9dddc293b9f1a230aba8e35d4f5af6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63154
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
SDMA write, copy, and ptePde use GPUMemMgr to write to device memory and
were dangerously not waiting for write completion which could result in
data not being completely written to memory, the data buffer being freed
and potentially reused in the simulator, or advancing to the next SDMA
packet before the previous one is complete.
This changeset adds callbacks for the corresponding "done" methods
similar to what the dmaVirt methods call when reading or writing to host
memory to fix this issue.
Change-Id: I44ce14c13f812ea2a7a76438e12a6ed7c6e0bff0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62715
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Requests sent using the GPU memory manager are not guaranteed to be
ordered. As a result, the last chunk created by the chunk generator
could complete before all of the previous chunks are done. This will
trigger the final callback and may cause an SDMA/PM4/etc. packet that is
waiting for its completion to resume before the data is ready.
This is likely a fix for verification failures in many applications.
Currently this is tested on MatrixTranspose from the HIP cookbook which
now passes its verification step. It could also potentially fix other
race conditions between reads/writes from/to memory such as using a PTE
or PDE before it is written, etc.
Change-Id: Id6fb342d899db6bd0b86c80056ecf91eeb3026f5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62714
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Now that the memory manager can DMA read from device memory, allow the
linear copy SDMA packet to use device memory as a source. This is used
when copying memory from device to host when SDMA engines are enabled.
This improves simulation performance over using (simulated) BLIT kernels
with SDMA engines disabled.
Change-Id: I1f41b294022f0049d154a401c1dc885abb4f223b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62713
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Using the register destination to store an immediate result causes the isa parser to set the destination as a dependency, meaning the destination register from previous instructions must have a ready result before this instruction can issue. I fixed several cases where this occurs by using a non register intermediary value
Change-Id: Id2ccca820a4e072fa2cae81fa9153deb6a8d5c4c
Signed-off-by: Noah Katz <nkatz@rivosinc.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63052
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 commit:
https://gem5-review.googlesource.com/c/public/gem5/+/62471
set `sim_quantum` for any simulation done via the Simulator module.
However, this causes issues when setting exit events at a particular
tick. It resulted in the exit being off by the `sim_quantum` value. This
is required for KVM setups but is undesirable for non-KVM setups. Ergo,
this commit ensures the `sim_quantum` is only set in cases where KVM
cores are included in a simulation.
There are two items of note here:
1. When using the SwitchableProcessor the KVM cores may be switched out
and therefore not accessable via the `get_cores` method. To get round
this we check if the processor is a SwitchableProcessor and run an
additionial check that _any_ of the cores in the SwitchableProcessor
are KVM. This is a big hacky; the Processor API should be changed to
make this easier.
2. This only partially fixes the problem of exit events being off given
a specified tick. This will still occur in the case a
SwitchableProcessor is used containing KVM cores. E.g., non-KVM cores
will still be "off" when KVM cores are switched out. This issue will
be addressed in a later commit.
Change-Id: Id966d76cd1630b6c41c5972fa9423c9e48eafaf6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63051
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 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>
