If an `AddrRange` is not interleaved, return the input address in
`removeIntlvBits` and `addIntlvBits` to prevent undefined behavior. It
allows to use these methods in all cases without having to check
manually whether the range is interleaved.
Change-Id: Ic6ac8c4e52b09417bc41aa9380a24319c34e0b35
Signed-off-by: Isaac Sánchez Barrera <isaac.sanchez@bsc.es>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37617
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
HSA packet processor will now accept and process agent packets.
Type field in packet is command type.
For now:
AgentCmd::Nop = 0
AgentCmd::Steal = 1
Steal command steals the completion signal for a running kernel.
This enables a benchmark to use hsa primitives to send an agent
packet to steal the signal, then wait on that signal.
Minimal working example to be added in gem5-resources.
Change-Id: I37f8a4b7ea1780b471559aecbf4af1050353b0b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37015
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These files are used to generate stubs for calling across GRPC
protocols, an RPC mechanism which is based around the protocol buffer
system.
The support for these files is heavily based on and calls into the
existing protobuf file support, but with the extra step which generates
the additional .grpc.pb.cc and .grpc.pb.h files.
Change-Id: I89022928c08aa9f7ed024b7380ddcc54ca75b55e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37277
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are several benefits to using a Builder. First, the action we're
executing is shared between all uses of the Builder. The number of
times this particular builder is called is small, but it should still
be a little more efficient.
Second, we can use SCons's emitter mechanism to generate the .pb.cc and
.pb.h target files in a little more general way.
Also, this change adds a Scanner for .proto files which will scan them
for imports and let SCons manage those implicit dependencies properly.
The scanner is a bit simplistic as described in a comment in the
source, but should work pretty well in practice with reasonably
formatted files, and in particular some files I'm working with that
include imports.
Change-Id: Iaf2498e61133d6f713d6ccaf199422b882c5894f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37276
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The ProtoBuf support in src/SConscript was split into two parts, one
where the ProtoBuf sources were declared, and the other where scons was
told how to buld the .cc and .hh files and the .cc was added to the
build.
As far as I can tell, there was no real reason to have things split up
like that, at least not currently. This change moves everything into
the ProtoBuf class definition, and this should behave the same as
before but be a little easier to understand and maintain.
Change-Id: I02320f50ece53d90c14b5062bd6b1167210f46c3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37275
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There were two issues with how paths were handled for these files.
1. The code in the ProtoBuf class would drop the subdirectory part of
the path name when generating the name of the .cc and .h files the
protoc compiler would output. Since protoc wouldn't generate files
where scons expected, it would fail when it tried to build the .cc.
2. protoc will use the --proto_path and --cpp_out settings to figure
out what path to use for generated files. It will remove the
--proto_path prefix it found the .proto file with from the files path,
and then add the rest to the --cpp_out prefix.
The input files should come from the build directory using symlinks
set up by scons, and the output files should end up alongside them.
That means the --proto_path setting should be the build directory, and
so should --cpp_out. That's fortunately simpler than what was there
before, since it doesn't depend on what the source or targets are.
Change-Id: I69692d2fe3813011982f0c1c9824589a132f93ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37218
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The function was defined in a .cc file but marked as inline. gcc seems
to often figure out what it should do, but in clang it doesn't export
the function (since it's marked as inline), and during linking external
references, which don't have a local copy since it's not defined in the
.hh file, will fail.
This failure looks particularly odd because the funciton is virtual,
and so the failure is reported as being unable to compose the vtable
in places where the object is constructed, relatively obscure code
which is generated by the build system and obscured by templates from
an external code base (pybind11).
Change-Id: Ib51aefbf9005e4ca8dfebef32c5def472175f115
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37436
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The compression factor of a block is measured according to the maximum
achievable compression ratio.
For example, if up to 4 blocks can co-allocate in a superblock, and
a cache line has 512 bits, the possible compression factors are 1
(uncompressed, <=512 bits), 2 (compressed, <=256 bits), 4 (compressed,
<=128 bits).
This is an approach similar to the one described in "Yet Another
Compressed Cache", by Sardashti et al.
Change-Id: I52ef36989f3eeef6fc8890132a57f995ef9c5258
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36581
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When setting the size of a compressed block, its compressibility
needs to be recalculated based on that, so move such functionality
to be done after the block has been inserted, within setSizeBits.
As a side effect, insertBlock does not need to be overridden
anymore.
Change-Id: I608f876cd2110ac5e394ffad5b29941ba458ba91
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36580
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Data contractions happen when a block passes from a less compressed
(e.g., uncompressed) to a more compressed (e.g., compressed) state.
Some compaction methods enforce that a block can only be allocated
in a location matches an exact compression factor, thus on data
contractions such blocks must be moved to another location, or
they must be padded to fake a bigger size.
For compaction methods that do not have that limitation, performance
can be improved if the contracted block is moved to co-allocate with
another existing entry, since it frees up an entry.
Change-Id: I302bc561b897f9d3ce1426331fe4b5c2df76f4b5
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36578
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When searching for victims of a data expansion a simple approach to
make room for the expanded block is to evict every co-allocatable
block. This, however, ignores replacement policies and tends to be
inefficient. Besides, some cache compaction policies do not allow
blocks that changed their compression ratio to be allocated in the
same location (e.g., Skewed Compressed Caches), so they must be
moved elsewhere.
The replacement policy approach asks the replacement policy which
block(s) would be the best to evict in order to make room for the
expanded block. The other approach, on the other hand, simply evicts
all co-allocated entries. In the case the replacement policy selects
the superblock of the block being expanded, we must make sure the
latter is not evicted/moved by mistake.
This patch also allows the user to select which approach they would
like to use.
Change-Id: Iae57cf26dac7218c51ff0169a5cfcf3d6f8ea28a
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36577
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some cache techniques may need to move a block's metadata information
into another block. This must have some limitations to avoid mistakes:
- The destination entry must be invalid, otherwise the replacement
policy steps would be skipped.
- The source entry must be valid, otherwise there would be no point
in moving their metadata contents.
- The entries locations (set, way, offset...) must not be moved, since
they are fixed. The same principle is applied to the location specific
variables, such as the replacement pointer
Why it would be used:
For example, when using compression, and a block goes from uncompressed
to compressed state due to an overwrite, after the tag lookup
(sequential access) it can be decided whether to store the new data in
the old location, or, since we might have already found the block's co-
allocatable blocks, move it to co-allocate.
Other examples of techniques that could use this functionality are
Skewed Compressed Caches, and ZCaches.
Change-Id: I96e4f8cc8c992c4b01f315251d1a75d51c28692c
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36575
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If the memory system can provide a back door to memory, store that, and
use it for subsequent accesses to the range it covers. For now, this
covers only fetch. That's because fetch will generally happen more than
loads and stores, and because it's relatively simple to implement since
we can ignore atomic operations, etc.
Some limitted benchmarking suggests that this speeds up x86 linux boot
by about 20%, although my modifications to the config to remove caching
(which blocks the back door mechanism) also made gem5 crash, so it's
hard to say for sure if that's a valid result. The crash happened in the
same way before and after, so it's probably at least relatively
representative.
While this gives a pretty substantial performance boost, it will prevent
statistics from being collected at the memory, or on intermediate objects
in the interconnect like the bus. That is to be expected with this
memory mode, however.
Change-Id: I73f73017e454300fd4d61f58462eb4ec719b8d85
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36979
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
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 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>
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>
