In the MemPool object, the idea of a limit of the pool (largest page)
and the total number of pages were conflated, as was the page number of
the next "free" page and the total number of pages allocated. Both of
those would only be equivalent if the memory pool starts at address
zero, which is not generally true and could be true for at most one pool
at a time even when it is occasionally true.
Instead, this change fixes up MemPool to keep tree values, a starting
page number, the page number of the next free page, and the total number
of pages in the pool, both allocated and unallocated.
With those three values, we can accurately report the number of
allocated pages (not just the number of pages of any kind below the next
free one), the total number of free pages, and the total number of pages
in general (not the largest numbered page in the pool).
The value serialized by the System class was adjusted so that it will
stay compatible with previous checkpoints. The value unserialized by the
system class is passed to the MemPool as a limit, which has not changed
and so doesn't need to be updated. It gets translated into the total
number of pages in the MemPool constructor.
Change-Id: I8268ef410b41bf757df9ee5585ec2f6b0d8499e1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50687
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Pass it in through the constructor, rather than have the MemPool call
into the System object every time it needs the page shift. This is
simpler, more efficient, and removes a dependency between the MemPool
class and the System class.
Change-Id: I059bcb0db249251b32bff1beba3eadfe306d9081
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50339
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Don't look for the m5opRange in the memory pools when allocating memory
so that it can be skipped, just exclude it from the memory pools
entirely when they are set up. This removes a dependence between the
memory pools and the system class.
Change-Id: I0d88c1bc2f889f32b234073cff8988319fb36ea5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50338
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now all occurances of the THE_ISA macro which were being used to check
for anything other than the NULL_ISA have been eliminated. We still need
to be able to check whether the current ISA is the null ISA, but we
don't want to let any preprocessor checks back in which are based on
what the current ISA is.
This change removes the THE_ISA macro, and replaces it with IS_NULL_ISA
which evaluates to 1 if the ISA is null, and 0 if it isn't.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1060
Change-Id: Iec146b40d8cab846dae03e15191390f754f2b71b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48709
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Device memories are used for PCI devices which have their own pools of
backing store memory such as amdgpu device. The check for an address
being in device memory previously did not handle multiple interleaved
memory devices with the same address range. Therefore, the device memory
check would fail if the interleaving masks did not match. This updates
the method to iterate through all device memories that handle the
RequestorID and returns true if any of the device memories contain the
packet address.
Change-Id: I9339d39c1cb54a5b9075c4a122c118fe61dc6fdb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46381
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
::Stats became ::statistics.
"statistics" was chosen over "stats" to avoid generating
conflicts with the already existing variables (there are
way too many "stats" in the codebase), which would make
this patch even more disturbing for the users.
Change-Id: If877b12d7dac356f86e3b3d941bf7558a4fd8719
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By moving the installation of even the first ThreadContext out of the
constructor, it's possible to construct the stub separately. We can then
move the code that creates the stub out of the base class and into
architecture specific sub-classes.
Change-Id: I0dfd53a3135ebc98ec49acf81d83e58830bc365c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44618
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
There are two user visible effects of this change. First, all of the
threads for a particular workload are moved under a single GDB instance.
The GDB session can see all the threads at once, and can let you move
between them as you want.
Second, since there is a GDB instance per workload and not per CPU, the
wait_for_gdb parameter was moved to the workload.
Change-Id: I510410c3cbb56e445b0fbb1def94c769d3a7b2e3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44617
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Only one is set up corrent, the one passed in from the constructor.
Others can be added with addThreadContext.
The inconsistency of adding one ThreadContext through the constructor
and others through addThreadContext isn't great, but this way we can
ensure that there is always at least one ThreadContext. I'm not sure
what the GDB stub should do if there aren't any threads. I don't think
that the protocol can actually handle that, judging from the
documentation I can find.
Change-Id: I9160c3701ce78dcbbe99de1a6fe2a13e7e69404e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44611
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When a segfault happens in the guest, report a SEGV trap to GDB (if
there is one attached) instead of bailing out immediately.
The obvious use-case for this, is the ability to debug guest crashes
in GDB in the standard manner.
The less-trivial use-case is for development of software in an
incomplete software stack (cf. Aarno-Engblom's "Virtual Platforms"
pp.105 et seq.) One particular example is Ingalls-Miranda simulation of
JIT compilers, where the VM's address space may be split between the
simulated and the real machine: in this case, GDB traps facilitate the
transparent illusion of an unbroken address space.
Change-Id: I9072ed5f6474e05e9a99dc42ae5754be28121355
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44685
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code which registers thread contexts originally returned the ID that
it had chosen, and let the CPU actually set the ID in the object itself.
That opened a window where calling contextId() on the ThreadContext
would return the wrong answer.
Instead, we can just set the ID immediately after it's decided. This
also localizes that logic and removes plumbing for the ID between that
decision and where it's actually applied.
Change-Id: I31ad84c3f9bf6f5b6f72457ca640ea929b24f6a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44615
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This unused pair of methods could be used to trigger a breakpoint within
the remote GDB stub, but was unused and would need to be called from an
instance of GDB attached to gem5 itself.
The system's version of breakpoint was also limitted in that it would
only cause a breakpoint in the first thread's GDB and no other.
Change-Id: I53ceab78667610177dbb8be1def3a88262befeec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44031
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When requestor id is requested, it is stripped of the System name via
the `stripSystemName` function in `system.cc`. However, there is a bug
in this code that leaves a leading ".". E.g.:
`system.cpu.mmu.dtb.walker` is stripped to `.cpu.mmu.dtb.walker`.
This patch fixes this issue.
Change-Id: I825cbc60c7f7eaa84c8a0150c30e9f2902cff6cb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41513
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The patch is using the newly defined PARAMS macro to replace
custom params() getters in derived class.
The patch is also removing redundant _params:
Instead of creating yet another _params field, SimObject descendants
should use params() to expose the real type of SimObject::_params they
already have.
Change-Id: I43394cebb9661fe747bdbb332236f0f0181b3dba
Signed-off-by: Alexander Klimov <Alexander.Klimov@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39900
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was mostly not used to begin with, but also when it was used, it
would obscure places where there were types, functions, etc, which were
switched between ISAs at compile time, and which would need to be
cleaned up to allow more than one ISA at a time.
Change-Id: Ieb372feff91b7e946b477fb78e54bcd0c2138966
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39655
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The create() method on Params structs usually instantiate SimObjects
using a constructor which takes the Params struct as a parameter
somehow. There has been a lot of needless variation in how that was
done, making it annoying to pass Params down to base classes. Some of
the different forms were:
const Params &
Params &
Params *
const Params *
Params const*
This change goes through and fixes up every constructor and every
create() method to use the const Params & form. We use a reference
because the Params struct should never be null. We use const because
neither the create method nor the consuming object should modify the
record of the parameters as they came in from the config. That would
make consuming them not idempotent, and make it impossible to tell what
the actual simulation configuration was since it would change from any
user visible form (config script, config.ini, dot pdf output).
Change-Id: I77453cba52fdcfd5f4eec92dfb0bddb5a9945f31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35938
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change replaces the __attribute__ syntax with the now standard [[]]
syntax. It also reorganizes compiler.hh so that all special macros have
some explanatory text saying what they do, and each attribute which has a
standard version can use that if available and what version of c++ it's
standard in is put in a comment.
Also, the requirements as far as where you put [[]] style attributes are
a little more strict than the old school __attribute__ style. The use of
the attribute macros was updated to fit these new, more strict
requirements.
Change-Id: Iace44306a534111f1c38b9856dc9e88cd9b49d2a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35219
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch adds the ability for a host-OS process external to gem5
to access the backing store via POSIX shared memory.
The new param shared_backstore of the System object is the filename
of the shared memory (i.e., the first argument to shm_open()).
Change-Id: I98c948a32a15049a4515e6c02a14595fb5fe379f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30994
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Adds support for device memories in the system and RubySystem classes.
Devices may register memory ranges with the system class and packets
which originate from the device MasterID will update the device memory
in Ruby. In RubySystem functional access is updated to keep the packets
within the Ruby network they originated from.
Change-Id: I47850df1dc1994485d471ccd9da89e8d88eb0d20
JIRA: https://gem5.atlassian.net/browse/GEM5-470
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29653
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The System class has a few different arrays of values which each
correspond to a thread of execution based on their position. This
change collects them together into a single class to make managing them
easier and less error prone. It also collects methods for manipulating
those threads as an API for that class.
This class acts as a collection point for thread based state which the
System class can look into to get at all its state. It also acts as an
interface for interacting with threads for other classes. This forces
external consumers to use the API instead of accessing the individual
arrays which improves consistency.
Change-Id: Idc4575c5a0b56fe75f5c497809ad91c22bfe26cc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25144
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Information about what kernel to load and how to load it was built
into the System object and its subclasses. That overloaded the System
object and made it responsible for too many things, and also was
somewhat awkward when working with SE mode which doesn't have a kernel.
This change extracts the kernel and information related to it from the
System object and puts into into a OsKernel or Workload object.
Currently the idea of a "Workload" to run and a kernel are a bit
muddled, an unfortunate carry-over from the original code. It's also an
implication of trying not to make too sweeping of a change, and to
minimize the number of times configs need to change, ie avoiding
creating a "kernel" parameter which would shortly thereafter be
renamed to "workload".
In future changes, the ideas of a kernel and a workload will be
disentangled, and workloads will be expanded to include emulated
operating systems which shephard and contain Process-es for syscall
emulation.
This change was originally split into pieces to make reviewing it
easier. Those reviews are here:
https: //gem5-review.googlesource.com/c/public/gem5/+/22243
https: //gem5-review.googlesource.com/c/public/gem5/+/24144
https: //gem5-review.googlesource.com/c/public/gem5/+/24145
https: //gem5-review.googlesource.com/c/public/gem5/+/24146
https: //gem5-review.googlesource.com/c/public/gem5/+/24147
https: //gem5-review.googlesource.com/c/public/gem5/+/24286
Change-Id: Ia3d863db276a023b6a2c7ee7a656d8142ff75589
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently the System class has a mechanism to wait for a GDB connection
for each CPU which has requested it through one of its parameters.
Unfortunately, not every thread context/CPU will be ready for GDB at
that point, particularly considering that in an FS simulation the
kernel won't have been read so there will be no symbols, none of the
registers or the entry point will have been set.
Also in the fast models, the CPUs haven't had a chance to initialize
themselves enough by that point to respond to the API calls which are
used to implement GDB support.
Change-Id: If27cb3e0259a1f67599ab0493695b2f8af640d8e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24963
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
