The SIMPOINT_BEGIN should do nothing by default since it might be used
in various cases.
In
[https://www.mail-archive.com/gem5-users@gem5.org/msg22383.html](mailing
list), a user discovered a bug with the current
`simpoints-se-restore.py` example.
The bug is caused by the default behavior of the SIMPOINT_BEGIN exit
event.
When taking a checkpoint with `simpoints-se-checkpoint.py`, it stores
the future exit event scheduled at the beginning of the simulation. I
did not notice this when I wrote and tested the example script due to
the long print out log and my custom handler of the SIMPOINT_BEGIN exit
event.
In the restoring, the SIMPOINT_BEGIN exit event was triggered right
before the region end, so it resets the stats before the final stats
dump. Therefore, the simulation time is 0 as the user discovered.
This patch should fix this bug.
Change-Id: I800dfbd28d7b2c842864a1ab7d84b8f8e17b9b3c
- There was a bug in JSONClient when searching
for resoruces. The id was not checked and
the booleans were not set to true when
optional search queries like resource_version
and gem5_version are not passed.
Change-Id: I4aa7c5388035144ec6864d57130ad09e6709692e
This commit adds more detailed instruction types for RISC-V Vector.
Concretely, it substitutes VectorIntegerArith, VectorFloatArith,
VectorIntegerReduce and VectorFloatReduce with more specific types
related to the operation that each instruction (e.g., VectorIntegerAdd
or VectorIntegerMult).
Additionaly, fixes two RISC-V instruction types (VectorXXX) that were
used in ARM SVE, placing the proper SimdXXX ones.
Change-Id: I31774fa6a7cd249abfffec68d11d3d77f08ad70b
CC @adriaarmejach
One of things we miss in gem5 is the capability to neatly compose the
cache hierarchy of CPUs and clusters of CPUs. The BaseCPU
addPrivateSplitL1Caches and addTwoLevelCacheHierarchy APIs have
historically been used to bind cache levels together.
These APIs have been superseded by the introduction of the Cache
hierarchy abstraction in the standard library. The standard library
makes it cleaner for a user to quickly instantiate a hierarchy of caches
with few lines of code. While this removes a lot of complexity for a
user, the Hierarchy objects still have little information about their
internal topology.
To address this problem, this patch adds a tree data structure to the
AbstractCacheHierarchy class, where every node of the tree represent
a cache in the hierarchy. In this way we will expose APIs for traversing
and querying the tree.
For example a 2 CPUs system with private L1, private L2 and shared L3
will contain the following tree:
[root]
|
[L3]
/\
/ \
[L2] [L2]
| |
[L1] [L1]
When the `statistics::nozero` flag is set gem5 does not output that stat
if its value is zero. This was not the case for SimStats which output in
this case. This patch correct this behavior.
This will just call the _m5.range.isSubset method
Change-Id: If747819a008a8ed20796b4efd42a42e5c3a8d7d9
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This change sets the `release` of the ARM board at the config file
instead of overriding the release on the ArmBoard. This change partially
solves issue 932 as the system taking and restoring the checkpoint is
consistent across KVM and timing CPUs respectively.
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Now that we are able to provide a view of the cache hierarchy from
the python world, we can start generating DTB entries for caches
and more specifically to properly fill the next-level-cache and
cache-level properties
Change-Id: Iba9ea08fe605f77a353c9e64d62b04b80478b4e2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
One of things we miss in gem5 is the capability to neatly compose the
cache hierarchy of CPUs and clusters of CPUs. The BaseCPU
addPrivateSplitL1Caches and addTwoLevelCacheHierarchy APIs have
historically been used to bind cache levels together.
These APIs have been superseeded by the introduction of the Cache
hierarchy abstraction in the standard library. The standard library
makes it cleaner for a user to quickly instantiate a hierarchy of caches
with few lines of code. While this removes a lot of complexity for a
user, the Hierarchy objects still have little information about their
internal topology.
To address this problem, this patch adds a tree data structure to the
AbstractCacheHierarchy class, where every node of the tree represent
a cache in the hierarchy. In this way we will expose APIs for traversing
and querying the tree.
For example a 2 CPUs system with private L1, private L2 and shared L3
will contain the following tree:
[root]
|
[L3]
/\
/ \
[L2] [L2]
| |
[L1] [L1]
Change-Id: I78fe6ad094f0938ff9bed191fb10b9e841418692
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit updates cpu by removing VectorXXX types and updates
FUs according to the newer SimdXXX ones. This is part of the
homogenization of RISCV Vector instruction types, which moved
from VectorXXX to SimdXXX.
Change-Id: I84baccd099b73a11cf26dd714487a9f272671d3d
This PR fixes#948 in which running KVM CPUs through the updated gem5
interface in SE mode causes an immediate crash.
To fix this, I added a check to set_se_binary_workload that checks if
any of the cores are KVM, and if so, sets a couple of knobs for the
board and process that are required to make KVM work. The depecated
se.py script, which sets these knobs, is able to run KVM in SE mode just
fine, so doing the same here fixed the bug.
From [1] The PrivateL1PrivateL2Cache hierarchy has been amended
with an MMUCache, which is basically a small cache in front
of the page table walker. Not every ISA makes use of it.
Arm for example already implements caching of page table
walks, via the partial_levels parameter in the ArmTLB.
With this patch we define a new module which explicitly makes
use of the WalkCache. Configurations that do not require
another cache in the first level of the memsys (for the ptw)
can use the PrivateL1PrivateL2CacheHierarchy
[1]: https://gem5-review.googlesource.com/c/public/gem5/+/49364
Change-Id: I17f7e68940ee947ca5b30e6ab3a01dafeed0f338
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Previously merged PR #886 created pic.hart_config, but it was not
initialized properly in lupv_board.py. This issue is causing daily tests
to fail.
Change-Id: I193ff4a3e5ef787eefcf066404e762f024fa6603
---------
Co-authored-by: Yu-Cheng Chang <aucixw45876@gmail.com>
This change adds a fatal statement to check all params for all
SimObjects have been unproxied before C++ object are created.
The fatal statement notifies the user of a mistake that could
possibly lead to a SimObject to not have its params unproxied.
This mistake could be made by adding a child SimObject with a
name that starts with an underscore.
Update the PLIC based on the
[riscv-plic-spec](https://github.com/riscv/riscv-plic-spec) in the PR:
- Support customized PLIC hardID and privilege mode configuration
- Backward compatable with the n_contexts parameter, will generate the
config like {0,M}, {0,S}, {1,M} ...
Change-Id: Ibff736827edb7c97921e01fa27f503574a27a562
This change improves the functionality of strided generator to create
trace with better flexibility.
It allows the user to manually set offset and stride size instead of
calculating it based on a "gen_id".
This way different patterns could be created with the same SimObject.
In addition, this change adds stdlib components for strided generator.
This change adds support to use KVM cores on the ARM board. The board
simulates gic to enable KVM, similar to the gem5 ARM FS configs. The
limitation is that it only supports VExpress_GEM5_V1.
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Due to a change introduced in https://github.com/gem5/gem5/pull/625, a
gem5 resource will not download any external files until
`get_local_path()` is called. In the construction of the Looppoint
Resources this function was not called, the `local_path` variable was
called directly. As such, an error occured.
The downside of this fix is the Looppoint resources external files are
downloaded when `obtain_resource` is called, thus the bandwidth savings
introduced with https://github.com/gem5/gem5/pull/625 will not occur for
Looppoint resources. However, https://github.com/gem5/gem5/issues/644
proposes a fix which would supercede the
https://github.com/gem5/gem5/pull/625 solution.
Change-Id: I52181382a03e492ec1cb58b01e71bc4820af9ccc
The value of a `WorkloadResource`'s additional parameter may not always
be a string. It can be any JSON value (integer, a list, a dict, ect.).
For Looppoint resources we have additional parameters such as a List of
region start points.
The assert inside workloads checking the type of the value breaks
certain usecase and is therefore removed in this commit.
Change-Id: Iecb1518082c28ab3872a8de888c76f0800261640
RISCV full system workloads have the capability of exit the simulation loop
upon the guest's kernel panic/oops. This change adds more stdlib exit event types
to accommodate the corresponding gem5 exits upon the guest's kernel panic and
kernel oops.
Change-Id: I3a4f313711793a473c6f138ff831b948034d0bb6
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
`get_runtime_isa()` has been deprecated for some time. It is a leftover
piece of code from when gem5 was compiled to a single ISA and that ISA
used to configure the simulated system to use that ISA. Since multi-ISA
compilations are possible, `get_runtime_isa()` should not be used.
Unless the gem5 binary is compiled to a single ISA, a failure will
occur.
The new proceedure for specify which ISA to use is by the setting of the
correct `BaseCPU` implementation. E.g., `X86SimpleTimingCPU` of
`ArmO3CPU`.
This patch removes the remaining `get_runtime_isa()` instances and
removes the function itself. The `SimpleCore` class has been updated to
allow for it's CPU factory to return a class, needed by scripts in
"configs/common".
The deprecated functionality in the standard library, which allowed for
the specifying of an ISA when setting up a processor and/or core has
also been removed. Setting an ISA is now manditory.
Fixes#216.
The [PR](https://github.com/gem5/gem5/pull/390) adds support for new
bootloader and linux kernel. However after applying the changes the
arguments are not passed correctly to the kernel resulting in kernel
panic during simulations. This commit fixes the issue.
This change decouple's the downloading of a resource from it's data.
With this change the `obtain_resource` function returns the
`AbstractResource` implementation which contains the data. The resource
itself (e.g., the actual disk image, binary, file, etc.) is only
downloaded to the host system, if not already present, upon the
`get_local_path` call.
`get_local_path` is the function used by gem5 to ultimately load the
resource into a simulation, therefore this change ensures we only
download resources when they are loaded into a simulation.
This change is not ideal and comes with the following caveats:
1. The `downloader` function is created in `obtain_workload` and passed
to the `AbstractResource` implementation for later use. This function
comes with the following requirements:
* The function will download the resource to `local_path`.
* The function will not re-download the resources if already present
as this function is called _everytime_ `get_local_path` is called.
2. The directories needed to store `local_path` are created in
`obtain_workload` regardless. Ergo even if the resource is not used and
`get_local_path` is never called these directories are still created.
In keeping with this efficiency `ShadowResource` is introduced to allow
the storing of just the resource ID and Version of a resource with
additional information only obtained when requested.
This change does the following,
- Change the name of several python parameter names of the
RiscvBootloaderKernelWorkload. This is done to conform the expectation
from the stdlib, e.g., the kernel path must be `object_file`, and the
boot parameter must be `command_line`.
- Use RiscvBootloaderKernelWorkload by default for all full system
RISC-V simulations. RiscvBootloaderKernelWorkload is a superset of
RiscvFsWorkload.
The purpose of a `ShadowResource` is a resource which only contains the
ID and Version information, not any additional information about the
resource thus avoiding the `obtain_resource` call.
When attributes of the `ShadowResource` are accessed which can only be
obtained via `obtain_resource` the `ShowResource` calls the function and
returns what is required.
This is useful for `Suite` resources which contain several workloads
and resources which may not all be needed when the `Suite` object is
first instantiated.
Change-Id: Icc56261b2c4d74e4079ee66486ddae677bb35cfa
This change decouple's the downloading of a resource from it's data.
With this change the `obtain_resource` function returns the
`AbstractResource` implementation which contains the data. The resource
itself (e.g., the actual disk image, binary, file, etc.) is only
downloaded to the host system, if not already present, upon the
`get_local_path` call.
`get_local_path` is the function used by gem5 to ultimately load the
resource into a simulation, therefore this change ensures we only
download resources when they are loaded into a simulation.
This change is not ideal and comes with the following caveats:
1. The `downloader` function is created in `obtain_workload` and passed
to the `AbstractResource` implementation for later use. This function
comes with the following requirements:
* The function will download the resource to `local_path`.
* The function will not re-download the resources if already present
as this function is called _everytime_ `get_local_path` is called.
2. The directories needed to store `local_path` are created in
`obtain_workload` regardless. Ergo even if the resource is not used and
`get_local_path` is never called these directories are still created.
Change-Id: I3f0e9a0099cba946630d719c3d17b7da0bccf74a
- The resources field in workload now changed to a dict of id and
version from a string with just the id.
There was an if statement added to support both versions in develop.
Removing the if statement so that 23.1 supports the new changes only.
Change-Id: Id8dc3f932f53a156e4fb609a215db7d85bd81a44
The CL updates the Kconfig:
1. Replace the USE_NULL_ISA with BUILD_ISA
2. The USE_XXX_ISAs are depends on BUILD_ISA
3. If the BUILD_ISA is set, at least one of USE_XXX_ISAs must be set
4. Refactor the USE_KVM option
Change-Id: I2a600dea9fb671263b0191c46c5790ebbe91a7b8
- resources field in workload now supports a dict with resources id and
version.
- Older workload JSON are still supported but added a deprecation waring
Recent breaking changes in the DRAMSys API require user code to be
updated. These updates have been applied to the gem5 integration.
Furthermore, as DRAMSys started to use CMake dependency management,
it is no longer sensible to maintain two separate build systems for
DRAMSys. The use of the DRAMSys integration in gem5 will therefore
from now on require that CMake is installed on the target machine.
Additionally, support for snapshots have been implemented into DRAMSys
and coupled with gem5's checkpointing API.
