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>
This patch introduces the GICv3 ITS module, which is in charge of
translating MSIs into physical (GICv3) and virtual (GICv4) LPIs. The
patch is only GICv3 compliant, which means that there is no direct
virtual LPI injection (this also means V* commands are unimplemented)
Other missing features are:
* No 2level ITS tables (only flat table supported)
* Command errors: when there is an error in the ITS, it is
IMPLEMENTATION DEFINED on how the ITS behaves. There are three possible
scenarios (see GICv3 TRM) and this implementation only supports one of
these (which is, aborting the command and jumping to the next one).
Furter patches could make it possible to select different reactions
* Invalidation commands (INV, INVALL) are only doing the memory table
walks, assuming the current Gicv3Redistributor is not caching any
configuration table entry.
Change-Id: If4ae9267ac1de7b20a04986a2af3ca3109743211
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/+/18601
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The system calls had four parameters. One of the parameters
is ThreadContext and another is Process. The ThreadContext
holds the value of the current process so the Process parameter
is redundant since the system call functions already have
indirect access.
With the old API, it is possible to call into the functions with
the wrong supplied Process which could end up being a confusing
error.
This patch removes the redundancy by forcing access through the
ThreadContext field within each system call.
Change-Id: Ib43d3f65824f6d425260dfd9f67de1892b6e8b7c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12299
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the open system call implementation in SE mode
treats /sys/ as a special path that is opened using a
special open handler. The ROC runtime, however, reads
several files in /sys/ that are supported via path
redirection. Here we remove /sys/ from the special files
so that the necessary files may be read via path
redirection.
Change-Id: Ifdab38ea1e6cc486ad43aec96b6e032fe63f137d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12127
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The current marshal binary is in $BUILD/python/ directory which makes
the dynamic linker fail to find shared libraries with rpath information
when the marshal is executing. Moving $BUILD/python/marshal to
$BUILD/marshal solves this problem.
This is because the marshal binary is built with the same flags as gem5
binary. And if one adds rpath information with add_local_rpath() in some
SConscripts, the marshal binary will also link to those shared libraries
and have the same rpath information. So it must be in the same
directory as gem5 binary such that the dynamic linker could find those
shared libraries with the rpath information.
Signed-off-by: Chun-Chen TK Hsu
Change-Id: I98d9c3e0180abefe6b2b6a78ee5a96324038eb53
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18888
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 a meta-prefetcher that enables gem5's cache models to
connect to multiple prefetchers. Sub-prefetchers still use the
probes-based interface and training can be controlled
independently. However, when the cache requests a prefetch packet, the
adaptor traverses the priority list of prefetchers and uses the first
prefetcher that is able to generate a prefetch.
Kudos to Mitch Hayenga for the original version of this patch.
Change-Id: I25569a834997e5404c7183ec995d212912c5dcdf
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18868
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This gets rid of the big mass of #if-s around headers and around the
code which creates an object file.
As a nice side bonus, this also means that in addition to supporting
multiple OS/arch combinations simultaneously, the object file loader
could support multiple ISAs simultaneously as well, since each could
load and set up its object file loaders indepedently and without the
base process classes knowledge/involvement.
Change-Id: I0a19ad06e30e9062a96d27f00b66756eb3a595ba
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18631
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This patch updates the FileSystemConfig so it works with more kinds of
config scripts (e.g., the Learning gem5 scripts).
There are 4 main changes:
- Added system as a parameter to the config_filesystem function so the
function can search the system for the number of CPUs instead of relying
on options from Options.py
- Instead of calling redirect_paths everywhere config_filesystem is
used, now it is implicitly called.
- Cleaned up the Ruby scripts a bit to remove redundant calls to
config_filesystem
- Added a config_filesystem call to the Ruby Learning gem5 script
(currently the only Learning gem5 script that requires it).
In the future, I think it would be better to move the config_filesystem
call into simulate.py, probably into the instantiate function. I tried to
use the per-CPU configuration parameters instead of options from
Options.py, but that's not possible until after the SimObject params
have been finalized in instantiate.
Change-Id: Ie6501a7435cfb3ac9d2b45be3722388b34063b1e
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18848
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
ARMv8.2 16-bit versions have not yet been implemented, but a placeholders
were created for them.
Refactor the nearby decoding tree to closely match the ARM spec A32 decode
table.
That piece of the tree can also be called from thumb which decodes it in
the same way, although the thumb decode table has a different terminology
The old code didn't match neither A32 or T32 terminologies, so it is
better to at least match one of them to help verify correctness.
Change-Id: Iabbbca2932557cf6c98ce36690c385c3ddf39ed8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18690
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Removed the icache/dcache hit latency parameters from the Sequencer.
They were replaced by the mandatory queue enqueue latency that is now
defined by the top-level cache controller. By default, the latency is
defined by the mandatory_queue_latency parameter. When the latency
depends on specific protocol states or on the request type, the protocol
may override the mandatoryQueueLatency function.
Change-Id: I72e57a7ea49501ef81dc7f591bef14134274647c
Signed-off-by: Tiago Muck <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18413
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Updating the message counter and enqueue times when adding blocked
messages back to the queue does not make a lot of sense since these
messages are not new arrivals.
More importantly, this may lead to starvation. See the scenario below:
1) Request A for a blocked line X arrives
2) A is handled; X is blocked so A is stalled
3) Request B for X arrives; Reponse for X arrives
4) Response is handled; X unblocked; A added back to the request queue
5) B is handled ahead of A (since A's arrival was updated);
X may become blocked again
If new requests keep comming for X, A may will be stalled forever.
Change-Id: Icad79f3f716a870e91cb3455437b8b3c35f130ac
Signed-off-by: Tiago Muck <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18412
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
