WriteCleanFull can be requested for the cache line in SD state (e.g.
Local eviction of a cache line in SD_RSC state). In this case, the
requestor is the owner of the cache line,
but it doesn't have it with exclusive right.
Thus, 'ownerIsExcl == false' should be removed from the stale condition.
Change-Id: I4d34021ac31b2e8600c24689a03a3b8fa18aa1f7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58412
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Initiate_CopyBack_Stale removes the requestor from the sharer list.
However, if CBWrData_SC is the data response of stale WriteCleanFull,
the requestor should remain in the sharer list.
Thus, whether to send a Evict or not can be decided after the data
response arrives. For this, FinishCopyBack_Stale event was added as the
last event to handle Evict.
Change-Id: Ic3e3a1e4d74b24b9aa328b2ddfa817db44f24e4e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58413
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Tiago Muck <tiago.muck@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This changes adds a new board to the gem5 stdlib, which is capable
of simulating an ARM based full system. It also adds an example
config script to perform a boot-test using an Ubuntu 18.04 disk
image. A test has been added in the gem5-library-example for the
same.
Change-Id: Ic95ee56084a444c7f1cf21cdcbf40585dcf5274a
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58910
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
In the prior design the AbstractBoard inherited from System. This was
fine for the X86Board and RISCVBoard, but was causing problems for the
design of the ARMBoard which must inherit from ArmSystem (which itself
inherits from System).
This new design removes the System inheritance from AbstractBoard, and
creates a new "AbstractSystemBoard" class which inherits from both
AbstractBoard and System. This allows for the creation of an ArmBoard
which inherits from both AbstractBoard and Arm System.
Change-Id: I3831f2ebe61e4adfb9dc10b7790b39403a99beaa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58909
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
During the memory requests, it's possible some control attribute
changed by IPs. There are three ways to model the behavior.
1. Modify the flags of current request, but there's no way to unset
the attribute now.
2. Clone the request with original flags, but there's no way to unset the
attribute.
3. Clone the request with zero flags, but it will ask the model to review
all the flags and set individually.
To preserve the original requests, we may pick the second approach. It's
still good to have clear modifiers to make the modeling more easier by
modifying the cloned request.
Change-Id: Ib216ca20c79b0f84be15ed4b0ec00354a428bac9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59809
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the is_valid statement in slicc requires that there is a
variable passed in as the only parameter. As far as I can tell, there's
no reason not to allow a more flexible expression. If we allow expr
instead of var, then we can eliminate unused variable warnings more
easily.
For instance, the following code won't compile with gem5.fast:
```
TBE tbe := getTBE(...);
assert(is_valid(tbe));
```
However, with this changeset we can fix the problem by using the
following code:
```
assert(is_valid(getTBE(...)));
```
Change-Id: I38a9f0dff9e942a387a8b2de655380d1af82afb8
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59830
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
If Ruby is disabled, then RubyNetwork is not a SimObject, and
do_ruby_dot which tries to reference it will crash. This more flexibly
checks for RubyNetwork, and if that isn't in m5.objects will gracefully
return instead of crashing.
Also streamline the code in that function a little bit using filter()
instead of preconstructing the list of ruby networks.
Change-Id: Ia4bdb04201df8453a1b6692a2f211b6cde00be2d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59629
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The nightly tests, https://jenkins.gem5.org/job/nightly/219/, were
failing with the following error when running build/NULL/unittests.opt:
```
[ENUMDECL] m5.objects.ArmSystem, ArmExtension -> NULL/enums/ArmExtension.hh
terminate called after throwing an instance of 'pybind11::error_already_set'
what(): ModuleNotFoundError: No module named 'm5.objects.ArmSystem'
At:
<frozen importlib._bootstrap>(973): _find_and_load_unlocked
<frozen importlib._bootstrap>(991): _find_and_load
<frozen importlib._bootstrap>(1014): _gcd_import
/usr/lib/python3.8/importlib/__init__.py(127): import_module
build_tools/enum_hh.py(58): <module>
Aborted (core dumped)
scons: *** [build/NULL/enums/ArmExtension.hh] Error 134
```
The reason for this is the 'aapcs64.test' now transitively includes the
'ArmExtension' enum via this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/59471.
As this test now only works with the ARM ISA, a guard has been included.
As noted in the comment, GTest does not have the 'tags' parameter so the
'TARGET_ISA' environment variable was used. This will need updated when
the multi-isa code is incorporated.
Change-Id: I2793094bf7c813afd97933750332fa3f3b7bd8dd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59569
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The Linux Kernel's printk mechanism and data structures were
overhauled in v5.10. This patch updates gem5's facility to dump the
kernel Dmesg buffer on kernel panic to account for these changes.
The new mechanism splits the Demsg ringbuffer into three separate
ringbuffers, one containing the message data, one containing
descriptors used for lock-free synchronisation, and one containing the
message infos. For a detailed description please see the header of
`kernel/printk/printk_ringbuffer.c` in the Linux source code.
The new gem5 implementation tests for the correct version to
run (pre-v5.10 or post-v5.10) by testing for the presence of symbols
in the kernel. The new, post-v5.10 dump code is templated on types
compatible with the kernel's atomic_long_t to account for differences
between the 64-bit and 32-bit Linux kernels.
Because the new Dmesg buffer dump code in gem5 is intended for
disaster recovery, it intentionally prints the full Dmesg buffer with
minimal checking of the validity of the messages. Partially finished
and/or uncommitted messages will be printed along with the finalised
messages.
Change-Id: I62ac20735e0679f1ba2062ca7bb13692a5ca1eae
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59509
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
ArmFastModelComponents must *minimally* be guarded by "arm fastmodel"
tags, but may actually be covered by a more specific tag which is a
subset of "arm fastmodel", for instance if they are controlled by a
kconfig variable and may or may not be included in "gem5 lib"
independently of other sources which are part of "arm fastmodel".
The contents set up by ArmFastModelComponent are already guarded by a
fixed tag, so this change just needs to plumb through the tag as
specified when the ArmFastModelComponent is created instead.
Change-Id: I619c31107acda378a5439718e32938843f024e74
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59473
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The AQL queue size is currently hardcoded to 64kB. For longer running
applications this causes the circular queue to wrap before reaching the
real end of the queue. Add the computation for queue size instead.
Previously longer applications (e.g., bc in pannotia) were hanging
around 4k kernels. With change the application launches 10k+ kernels.
Change-Id: I6c31677c1799a3c9ce28cf4e7e79efcb987e3b7f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59449
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
The data allocated for the DMA request used to send an interrupt cookie
was too large. This was causing the memcpy to occasionally seg fault due
to reading past the bounds of the source parameter (the interrupt cookie
struct). Correct the size and add a compile time check to ensure it is
the correct number of bytes expected by the driver.
Change-Id: Ie9757cb52ce8f72354582c36cfd3a7e8a1525484
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58969
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Profiling gem5 has indicated computeAddrTop as one of the main
contributors in AArch64 simulation time
The utility function gets used in the critical path of gem5, which is
the memory translation subsystem. The function is supposed to compute a
rather trivial task: identifying the "real" most significant bit of a
virtual address.
This turns out to be quite expensive. Why?
The main issue is the AArch32/AArch64 check, which uses the ELIs32
helper. This performs a sequential read of several MiscReg
values until it confirms that an EL is indeed using AArch32 (or
AArch64).
This is functionally accurate but it is too expensive for the critical
path of a program.
This patch is addressing the issue by adding a Memoizer object for the
computeAddrTop function to the CachedState data structure, which is
already holding cached system register values for performance reasons.
Whenever we need to invalidate those sys reg values because of a change
in the translation system, we also flush/invalidate the memoizer cache
Change-Id: If42e945c650c293ace304fb4c35e709783bb82d4
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59151
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Via the "GEM5_RESOURCE_JSON" environment variable, a user can override
the the default resources.json retrieval location. E.g., a user can have
their own resources.json file and load it instead. This may be a local
file path or a URL.
Code has been changed in downloader.py to allow the loading of
resources.json from either a URL or a local file path. Previously only
URLs were valid.
Change-Id: I022eee58efadc4819069563e9046ce9d84e5cf06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59069
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 patch is splitting the purifyTaggedAddr helper in two
by introducing the maskTaggedAddress utility
* The first part computes the top bit of the address (computeAddrTop)
(This is required as the MSBs of a VA could be used to store
tags like in FEAT_Pauth)
* The second part applies some masking to the supplied
address (maskTaggedAddress) depending on the top bit to
purify the VA from the TAG
The motivation of this split will be clear in the next patch:
we want to memoize the expensive computeAddrTop. Memoizing
purifyTaggedAddr is inefficient as the first argument
is the VA of the memory request so multiple memory requests
will allocate multiple entries in the results cache and
memoization will rarely be used.
We will memoize the VA agnostic computeAddrTop instead
Change-Id: Ib3d8bb521be67a1f21c0891e753396299adf500b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59150
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This class implements a generic memoization object:
It takes a function as a constructor argument and memoizes
it. Every time the function gets invoked through the Memoizer object
the result gets saved in the internal cache, ready
to be retrieved next time an invokation is made with the same
arguments.
Example usage:
int fibonacci(int n);
Memoizer fibonacci_memo(fibonacci);
fibonacci_memo(5);
There are two ways to discard a memoization
1) Delete the Memoizer object
2) Use the Memoizer::flush method
In some cases there is little or no reason to discard a memoization
(like in the fibonacci example, where fibonacci(k) always returns
the same value for the same input k)
The memoizer could be used in more complex cases, where a change in
the global state affects the output of the function, which
effectively invalidates the cached results.
It is up to the client to understand when memoization is no longer
valid and to flush the result cache as a consequence.
Change-Id: I6cf496b2aef5a66f5375a627165b2cb2e3a1bfc2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59149
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
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>
