Add a try_getbyte function that feature a timeout. This function uses
select to detect update on the file descriptor used to communicate with
the remote.
It is used to implement getbyte and to clean the file
descriptor before sending a message with send.
Now getbyte and send can recover from certains error like interruption
by other signals (EINTR) or delays causing the remote server to send
error packet to the stub.
Change-Id: Ie06845ba59dee0ad831632d5bc2b15132c9d5450
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63526
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.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>
The
'configs/example/gem5_library_example_tests/test_gem5_library_examples.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: Ib985433786c99c37794a1c67cc4337a5dfd0498d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64091
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 map was originally used for fast access to the GART table. It is no
longer needed as the table has been moved to the AMDGPUVM class. Along
with commit 12ec5f9172 which reads
functionally from device memory, this table is no longer needed and is
essentially a duplicate copy of device memory for anything written over
the PCI BAR.
This changeset removes the map entirely which will reduce the memory
footprint of simulations and potentially avoid stale copies of data
when reading over the PCI BAR.
Change-Id: I312ae38f869c6a65e50577b1c33dd055078aaf32
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63951
Reviewed-by: Matt Sinclair <mattdsinclair.wisc@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Previously the L1 request and response latencies were not configurable
in the GPU config scripts. As a result, the simulations used the default
values from GPU.py. This commits adds support to change this value as an
input parameter. The parameters to use are "--mem-req-latency" followed
by the value and "--mem-resp-latency" followed by the value. The default
values are the same as those in GPU.py (which is 50). These new
parameters should be set instead of changing the mandatory queue latency when configuring the L1 cache.
Change-Id: I812d77758ea12530899953f308c91f4c8b05866d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63971
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Previously the LDS bus latency was not configurable in the GPU config
scripts. As a result, the simulations would use the default value from
GPU.py. This commit adds support to change this value as an input
option. The option to use is "--vrf_lm_bus_latency".
Change-Id: I8d8852e6d7b9d03ebec1fe8b392968f396dd3526
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63652
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair.wisc@gmail.com>
AddrRangeMap::intersects doesn't support ranges with different
interleavings, thus the current implementation of the destination
seach won't work in cases when different machines map the same address
with different interleaving.
The fixed implementation uses a different AddrRangeMap for each mach
type.
Change-Id: Idd0184da343c46c92a4c86f142938902096c2b1f
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63671
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
In AmbaToTlmBridge we copy the control signal from amba extension to
SystemC extension. This makes gem5 models can proceed the correct
control signals. We need to make the same thing in AmbaToTlmBridge for
fastmodel can proceed the correct control signals.
A practical example is given a request is generated by fastmodel CPU,
translated by gem5 MMU, and routed to a fastmodel target. The secure bit
may be changed by MMU according to the PTE. We need to update the amba
extension in AmbaFromTlmBridge to make the target get the correct
information.
Change-Id: I600be7ba21368f00c05426ac1db3c28efd6ca2ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63773
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Given a data path initiated from SystemC, routed by gem5, and handled
by SystemC finally.
SystemC -> gem5 -> SystemC
The target SystemC needs to get the original transaction object.
Otherwise, it would lose the extensions in the payload.
To fix the issue, we moves the SenderState class to public for reachibility.
After that, we refactor the logic converting between payload and packet
to make sure they can use the correct instance. Finally, we fix the
potential address change during routing.
Change-Id: Ic6d24e98454f564f7dd6b43ad8c011e1ea7ea433
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63771
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This part of the Kokoro presubmit tests was designed to ensure gem5
still compiled sucessfully with Clang and to the '.fast' variant. ARM
was chosen arbitarily. Now that ALL exists, it makes more sense to use
it for this test.
Change-Id: Ia3593f7dd506205da13802a69094f4dd7019ab90
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63371
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Modeled after the HiFive Unmatched.
For the cache, we inherited from AbstractClassicCacheHierarchy and
AbstractTwoLevelCacheHierarchy to make a PrivateL1PrivateL2 hierarchy
with the same associativity and sizes as the board. However, the L2
Size is kept as a parameter that can be set by the user.
The core is in-order, therefore we inherited from RISC-V MinorCPU and
used the same pipeline parameters as the ARM HPI CPU, except the
decodeToExecuteForwardDelay, which was increased to 2 to avoid a
PMC access fault.
For the processor, we initialized the core with an ID so that we can
return 4 cores in FS mode, which is the same as the real system,
and 1 in SE mode.
For the memory, we just have a single channel DDR4_2400 with a size of
16 GB and starting at 0x80000000.
For the board, we declared a Boolean variable as a parameter to assign
whether it is in FS mode or not. We inherited from KernelDiskWorkload
and SEBinaryWorkload and initialized the components of the board
according to the Boolean. The other parameters are the clock frequency
and the L2 cache size.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1257
Change-Id: Ic2c066bb3a41dc2f42566ce971f9a665542f9771
Co-authored-by: Jasjeet Rangi <jasrangi@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63411
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The KVM_ISA setting was moved into a CONF dict, but the code which
ensured it had a default if there was no possible KVM hosting ISA was
still setting that variable in the base environment dict. This moves
the setting into the CONF dict instead.
Change-Id: I067c969dd761b2cdb098bcba6cd6a4b643d2d427
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63752
Reviewed-by: Earl Ou <shunhsingou@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Finish_CopyBack_Stale is scheduled only when the requestor is the last
sharer. This prevents the cacahe evicting the line which was already
evicted while the stale WriteBack transaction was stalled.
Wrong condition check in Finish_CopyBack_Stale for eviction is also
removed.
Change-Id: Ib66acc1b9e4a6f7cea373e1fb37375427897d48d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63611
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
While the `runtime` module's `get_runtime_isa` function throws a warning
to remind user's the function is deprecated, this was not always helpful
to a user when setting a processor without a target ISA.
This change adds additional warnings to the SimpleSwitchableProcessor
and the SimpleProcessor. These warnings explain not explicitly setting
the ISA via the processor's constructor is deprecated behavior.
Change-Id: I994ad8355e0d1c3f07374bebe2b59106fb04d212
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63331
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
