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>
Some platforms are not GICv4 compatible, therefore we need to make sure
the stride between redistributors is configurable:
2 frames of 64KiB for GICv3 => a stride of 128KiB
4 frames of 64KiB for GICv4 => a stride of 256KiB
We detect this at runtime by reading the GICD_PIDR2.ArchRev bitfield
This is 3 for GICv3 and 4 for GICv4.
Note: other software projects [1] rely on a different check, mainly
reading the GICR_TYPER.VLPIS bit
We diverge from this behaviour as VLPIS are not implemented and we do
not want to incorrectly report this to the probing software.
We should move to VLPIS once they get implemented
[1]: https://github.com/torvalds/linux/blob/\
107c948d1d3e61d10aee9d0f7c3d81bbee9842af/\
drivers/irqchip/irq-gic-v3.c#L864
Change-Id: I7cc554f48cc6a347c03ed80cf2ea320f618a59c2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59394
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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>
Apparently, sometimes a SCons Value node created with an integer value
0 will have a string representation which is the empty string, which
is obviously problematic. To work around this bug, convert the value
to a string explicitly before creating the Value node, so that we get
a sensible translation instead.
Change-Id: I4a09b2fb366aaf2d4d1c7e6f8cc84224b2d010c4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59472
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Current way of initializing GICv3 in the gem5 bootloader doesn't
work when there is a PE labelled with non-zero Aff1, Aff2 or Aff3
in the MPIDR_EL1 register
(For example in a multi-cluster configuration).
This is because the bootloader is considering Aff0 only
mrs x0, mpidr_el1
// extract the primary CPU.
ldr x1, =0xff00ffffff
and x2, x0, #0xff // use Aff0 as cpuid for now...
With this patch we are solving the issue, by considering
every affinity number. Now the primary cpu is the cpu with
Aff3..Aff0 = 0.
The bootloader was also using Aff0 (stored in x2, see above)
to let every CPU index their own redistributor memory mapped frames.
In this model every secondary CPU was in charge of initializing
their own redistributor registers.
This can't be used anymore as we have a tuple of affinity
numbers now rather than a single flat index.
We are addressing the issue by letting the primary cpu initialize
every redistributor in the system. This is done by iterating
over consecutive frames and by reading GICR_TYPER.Last, which
is set to 1 if the current frame is the last one.
Change-Id: I2bcad286c2282bf1c47618e5391bf1c2e2b27013
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59393
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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>
Prior to this patch those building from these Dockerfiles could
encounter caching issues where the `apt -y update` RUN was loaded from a
cached layer prior to running the `install` command. Typically this was
trying to obtain a package from a wrong IP address. The fix for this is
to run this all in one Docker RUN to avoid loading a broken cache.
Change-Id: If309c5c1d4a0240fed670abe980772d90f7d2172
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59350
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@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>
Add a longer test for the GPU Ruby random tester to the nightly
regression. This test is sized to take approximately 30 minutes
while providing more coverage than the per check-in Ruby random test,
which takes 30 seconds.
Change-Id: I398feb1283b24f801275ba13d6c53d236849f2eb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59272
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.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>
