Previously an AddrRange could express interleaving using a number of
consecutive bits and in additional optionally a second number of
consecutive bits. The two sets of consecutive bits would be xored and
matched against a value to determine if an address is in the
AddrRange. For example:
sel[0] = a[8] ^ a[12]
sel[1] = a[9] ^ a[13]
where sel == intlvMatch
This change extends AddrRange to allow more flexible interleavings
with an abritary number of set of bits which do not need be
consecutive. For example:
sel[0] = a[8] ^ a[11] ^ a[13]
sel[1] = a[15] ^ a[17] ^ a[19]
where sel == intlvMatch
Change-Id: I42220a6d5011a31f0560535762a25bfc823c3ebb
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19130
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
The flags may be passed as:
scons CCFLAGS_EXTRA='-Wno-error -pedantic' \
LDFLAGS_EXTRA='-g -g' build/<arch>/gem5.opt
The initial motivation for this commit is to help disable warning that
have become errors while bisecting.
scons orders the flags by Append call order, and ideally these flags
should be added last to override the others, since the last GCC flags
take precedence. However I haven't found a simple way to put them at
the very end.
Change-Id: Ida24dfb9604d88b99f113392ab5e47d578ba7259
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19048
Reviewed-by: Juha Jäykkä <juha.jaykka@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is an implementation of the SMMUv3 architecture.
What can it do?
- Single-stage and nested translation with 4k or 64k granule. 16k would
be straightforward to add.
- Large pages are supported.
- Works with any gem5 device as long as it is issuing packets with a
valid (Sub)StreamId
What it can't do?
- Fragment stage 1 page when the underlying stage 2 page is smaller. S1
page size > S2 page size is not supported
- Invalidations take zero time. This wouldn't be hard to fix.
- Checkpointing is not supported
- Stall/resume for faulting transactions is not supported
Additional contributors:
- Michiel W. van Tol <Michiel.VanTol@arm.com>
- Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: Ibc606fccd9199b2c1ba739c6335c846ffaa4d564
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19008
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Adding an option to enable DRAM low-power states. The low power
states can have a significant impact on application performance
(sim_ticks) on the order of 2-3x, especially for compute-gpu apps.
The options allows for it to easily be enabled/disabled to compare
performance numbers. The option is disabled by default.
Change-Id: Ib9bddbb792a1a6a4afb5339003472ff8f00a5859
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18548
Reviewed-by: Wendy Elsasser <wendy.elsasser@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add NUMBER_BITS_PER_SET environment variable to control
the size of the bitmask in Set.hh (default=64).
Necessary for configs which require >64 instances of a given
machine type. This can be set in the build_opts file, e.g.
by adding the following line:
NUMBER_BITS_PER_SET = <number>
Change-Id: I314a3cadca8ce975fcf4a60d9022494751688e88
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18968
Reviewed-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This reverts commit bf0a722acd.
Reason for revert: This patch introduces a bug:
The problem here is that the insertion of block A may cause the
eviction of block B, which on the lower level may cause the
eviction of block A. Since A is not marked as present yet, A is
"safely" removed from the snoop filter
However, by reverting it, using atomic and a Tags sub-class that
can generate multiple evictions at once becomes broken when using
Atomic mode and shall be fixed in a future patch.
Change-Id: I5b27e54b54ae5b50255588835c1a2ebf3015f002
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19088
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch adds support for pinning registers for a certain number of
consecutive writes. This is only relevant for timing CPU models
(functional-only models are unaffected), and it is primarily needed to
provide a realistic execution model for micro-coded operations whose
microops can write to non-overlapping portions of a destination
register, e.g. vector gather loads. In those cases, this mechanism
can disable renaming for a sequence of consecutive writes, thus making
the resulting execution more efficient: allocating a new physical
register for each microop would introduce a read-modify-write chain of
dependencies, while with these modifications the microops can write
back in parallel.
Please note that this new feature is only leveraged by O3CPU for the
time being.
Additional authors:
- Gabor Dozsa <gabor.dozsa@arm.com>
Change-Id: I07eb5fdbd1fa0b748c9bdc1174d9f330fda34f81
Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/13520
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This expands those functions into code which extracts the virt proxy
and then uses the appropriate method on it. This has two benefits.
First, the Copy* functions where mostly redundant wrappers around the
methods the proxy port already had. Second, using them forced a
particular port which might not actually be what the user wanted.
Change-Id: I62084631dd080061e3c74997125164f40da2d77c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18575
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Set the default release to that single value for all ISAs.
glibc has checks for the kernel version based on uname, and refuses
to start any syscall emulation programs if those checks don't pass with
error:
FATAL: kernel too old
The ideal solution to this problem is to actually implement all missing
system calls for the required kernel version and bumping the release
accordingly.
However, it is very hard to implement all missing syscalls and verify
compliance.
Previously, we have simply bumped the version manually from time to
time when major glibc versions started breaking.
This commit alleviates the problem in two ways.
Firstly, having a single kernel version for all versions means that it is
easier to bump all versions at once.
Secondly, it makes it is possible to set the release with a parameter,
which in turn can be set from the command line with:
se.py --param 'system.cpu[:].workload[:].release = "4.18.0"'
Change-Id: I9e3c31073bfe68735f7b0775c8e299aa62b98222
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17849
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The void * type is for pointers which point to an unknown type. We
should use that when handling anonymous buffers in the PortProxy
functions, instead of uint8_t * which points to bytes.
Importantly, C/C++ doesn't require you to do any casting to turn an
arbitrary pointer type into a void *. This will get rid of lots of
tedious, verbose casting throughout the code base.
Change-Id: Id1adecc283c866d8e24524efd64f37b079088bd9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18571
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The idea of a "secure" memory area/access is specific to ARM and
shouldn't be in the common mem directory, although it's built in to the
generic memory protocol at this point.
Regardless, it should minimially be in its own file like the virtual
and physical port proxy classes are.
Change-Id: I140d4566ee2deded784adb04bcf6f11755a85c0c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18569
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Changed SnoopMask to use std::bitset instead of uint64 so we can simulate
larger systems without having to workaround limitations on the number of
ports. No noticeable performance drop was observed after this change.
The size of the bitset is currently set to 256 which should fit most
needs.
Change-Id: I216882300500e2dcb789889756e73a1033271621
Signed-off-by: Tiago Muck <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18791
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
