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>
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>
