The methods `AddrRange::removeIntlvBits(Addr)` and
`AddrRange::addIntlvBits(Addr)` should be the inverse of one another,
but the latter did not insert the blanks for filling the removed bits in
the correct positions. Since the masks are ordered increasingly by the
position of the least significant bit of each mask, the lowest bit that
has to be inserted at each iteration is always `intlv_bit`, not needing
to be shifted to the left or right. The bits that need to be copied
from the input address are `intlv_bit-1..0` at each iteration.
The test `AddrRangeTest.AddRemoveInterleavBitsAcrossRange` has been
updated have masks below bit 12, making the old code not pass the test.
A new `AddrRangeTest.AddRemoveInterleavBitsAcrossContiguousRange` test
has been added to include a case in which the previous code fails. The
corrected code passes both tests.
This function is not used anywhere other than the tests and the class
`ChannelAddr`. However, it is needed to efficiently implement
interleaved caches in the classic mode.
Change-Id: I7d626a1f6ecf09a230fc18810d2dad2104d1a865
Signed-off-by: Isaac Sánchez Barrera <isaac.sanchez@bsc.es>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37175
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The variable 'm_allow_zero_latency' was only used in an assert message in
`src/mem/ruby/network/MessageBuffer.cc`. This assert is stripped when
compiling to gem5.fast, resulting in the compilation failing with an
unused variable error.
This assert is better as a panic_if, which will not be stripped out
during the .fast compilation.
Change-Id: I5de74982fa42b3291899ddcf73f7140079e1ec3f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36697
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
For the next release of gem5, we are dropping support for Python2. The
Ubuntu 18.04 Docker images were running with Python2. This has been
updated.
It should be noted that there is, at present, no eligant solution to the
issue that older versions of Scons (such as that obtainable via APT in
Ubuntu 18.04) use Python2. Those wishing to compile with these Docker
Images should use
`/usr/bin/env python3 $(which scons) build/X86/gem5.op5`
Change-Id: Ic36ecc7196688daff21af2bb3a76381966f38f60
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36595
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Previously the SimpleMem depended on the fact that it inherited from the
AbstractMem in order to access and export it's back door. Now, the
AbstractMem has a method which will set a back door pointer if
appropriate, which the SimpleMem can use, or anything else which uses an
AbstractMem as its backing store.
Also, make the AbstractMem invalidate any existing back doors and refuse
to give out any new ones while some bit of memory is locked. That's
because if the storage is accessed directly, the AbstractMem will have
no change to manage its bookkeeping, and locking won't work properly.
Change-Id: If8c2a63e0827bb88b583f27ab4151d6b761e116e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36977
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
There were accessors for reading these indexes, but they were not
consistently used. This change makes them private to StaticInst, and
changes places that were accessing them directly to instead use the
accessors. New accessors are added for code generated by the ISA parser
and some ARM code to set the indexes without accessing them directly.
By forcing these values to be behind accessors, it will be much simpler
to change how those values are stored and retrieved.
Change-Id: Icca80023d7f89e29504fac6b194881f88aedeec2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36875
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch adds the GPU protocol tester that uses data-race-free
operation to discover bugs in GPU protocols including GPU_VIPER. For
more information please see the following paper and the README:
T. Ta, X. Zhang, A. Gutierrez and B. M. Beckmann, "Autonomous
Data-Race-Free GPU Testing," 2019 IEEE International Symposium on
Workload Characterization (IISWC), Orlando, FL, USA, 2019, pp. 81-92,
doi: 10.1109/IISWC47752.2019.9042019.
Change-Id: Ic9939d131a930d1e7014ed0290601140bdd1499f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32855
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Several TLB invalidation instructions rely on VMID matching. This is
only applicable is EL2 is implemented and enabled in the current state.
The code prior to this patch was making the now invalid assumption that
we shouldn't consider the VMID if we are doing a secure lookup. This is
because in the past if we were in secure mode we were sure EL2 was not
enabled.
This is fishy and not valid anymore anyway after the introduction of
secure EL2.
Change-Id: I9a1368f8ed19279ed3c4b2da9fcdf0db799bc514
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35242
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change is useful when using custom simulation scripts that do not
rely on configs/common/Options.py.
Without this change, the custom script always needed to provide some
value for cache sizes and HW prefetchers configuration; with this change
it is possible to provide no value and use what is defined in the core
configuration as default.
Change-Id: Id0e807c3fa224180d682f366c7307941bab8ce59
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36776
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
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 gets rid of the requirement to only modify one byte register at a
time, and builds some structure around individual DMA channels.
The one small feature of the i8237 that was implemented is still
implemented, but now with a method of the i8237.
Change-Id: Ibc2b2d75f2a3b860da3f28ae649c6f1a099bdf7d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36815
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This verifies that the slightly more complex --addr command line option
behaves as expected.
Also, like the inst and semi call type unit tests, it will either
attempt to successfully perform a call to the "sum" m5 op if it's told
it's running under gem5, or it will attempt to catch itself failing to
run that command by using mprotect to block its access to the mmap-ed
region and then looks at the siginfo_t to make sure the attempted access
was to the right place, etc.
It also will attempt to verify the details of the mmap if possible by
looking up information about its own mmap-ings in /proc. If the file it
would expect to find the mappings in doesn't exist, it prints a warning
and gives up. If it does, it looks through it to find the line
corresponding to the m5 ops, and then checks some details of the mapping
like its size and its offset in the target file. The offset would
correspond to the physical address if using the real /dev/mem.
Change-Id: Icc14cd9ac02eae93c56f1f2aa78fd67d8540a2f2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27751
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Modern libraries such as ROCm, MPI, and libnuma use files in Linux'
sysfs to determine the system topology such as number of CPUs, cache
size, cache associativity, etc. If Linux does not recognize the vendor
string returned by CPUID in x86 it will do a generic initialization
which does not include creating these files. In the case of ROCm
(specifically ROCt) this causes failures when getting device properties.
This can be solved by setting the vendor string to, for example,
AuthenticAMD (as qemu does) so that Linux will create the relevant sysfs
files. Unfortunately, simply changing the string in cpuid.cc to
AuthenticAMD causes simulation slowdown and may not be desirable to all
users. This change creates a parameter, defaulting to M5 Simulator as it
currently is, which can be set in python configuration files to change
the vendor string. Example of how to configure this is:
for i in range(len(self.cpus)):
for j in range(len(self.cpus[i].isa)):
self.cpus[i].isa[j].vendor_string = "AuthenticAMD"
Change-Id: I8de26d5a145867fa23518718a799dd96b5b9bffa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36156
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A memory willing to autogenerate child nodes can do that directly in
the generateDeviceTree method. However sometimes portions of memory
(child nodes) are tagged for specific applications. Hardcoding the
child node in the parent memory class is not flexible, so we delegate
this to the application model, which is registering the generator
helper via the ParentMem interface
JIRA: https://gem5.atlassian.net/browse/GEM5-768
Change-Id: I5fa5bac0decf5399dbaa3804569998dc5e6d7bc0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34376
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
