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>
Turn the functions within it into virtual methods on the ISA classes.
Eliminate the implementation in MIPS, which was just copy pasted from
Alpha long ago. Fix some minor style issues in ARM. Remove templating.
Switch from using an "XC" type parameter to using the ThreadContext *
installed in all ISA classes.
The ARM version of these functions actually depend on the ExecContext
delaying writes to MiscRegs to work correctly. More insiduously than
that, they also depend on the conicidental ThreadContext like
availability of certain functions like contextId and getCpuPtr which
come from the class which happened to implement the type passed into XC.
To accomodate that, those functions need both a real ThreadContext, and
another object which is either an ExecContext or a ThreadContext
depending on how the method is called.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1053
Change-Id: I68f95f7283f831776ba76bc5481bfffd18211bc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50087
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a unit test for sim/serialize.hh.
==Bugs==
arrayParamIn cannot parse strings with spaces. Since spaces
are used as delimiters, strings containing spaces are parsed
as multiple entries of the array. The test that checks for
this has been disabled.
==Unexpected Behavior==
Serialization has an unexpected behavior when returning to
previous scopes. For example,
...
SCS scs(cpt, "S1")
paramOut(cpt, "param1", integer1)
{
SCS scs_2(cpt, "S2")
paramOut(cpt, "param2", integer2)
}
paramOut(cpt, "param3", integer3)
will generate the output:
...
[S1]
param1=1
[S2]
param2=2
param3=3
But the user might expect:
...
[S1]
param1=1
[S2]
param2=2
[S1]
param3=3
==Incovenient Behavior==
arrayParamIn with a std::array parameter is slightly
incovenient, since the raw data pointer must be extracted.
It may be worth it to add a template specialization.
==Not Tested==
paramInImpl is not being directly tested because it should
not be used as an external API - paramIn and optParamIn
should be used instead.
arrayParamIn with an InsertIterator parameter is not being
directly tested because the other versions should be used
instead.
Change-Id: If0c8f045aa317790d5fcb32e48629b113b62efc5
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41337
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
It is currently not possible to call m5.fork when the simulator is
running in with multiple parallel event queues. The POSIX standard
have very weak guarantees when forking a process with multiple
threads. In order to use fork correctly, we need to ensure that all
helper threads servicing event queues have terminated before the fork
system call is invoked.
There are two ways this could be implemented: 1) Always terminate
helper threads when taking a global simulator exit event, or 2)
terminate helper threads just before fork is called from Python.
This change implements the second strategy since the KVM-based CPUs
currently assume that TIDs don't change unless there is a fork event.
Change-Id: I22feaecd49f7f81689b43185d63a8f14428bed63
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50408
Reviewed-by: Austin Harris <mail@austin-harris.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
The deprecated attribute didn't work on versions of gcc older than 6,
but we now require version 7 or newer, so we don't need the macro any
more.
This change collapses the two uses of it in sim/aux_vector.hh, and marks
the macro as deprecated by extending the message string in the
underlying deprecated attribute.
Change-Id: I3bc9835ba19ad9534c7725e17a3558a749a94ca5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48514
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Now that we're using c++17, the type_traits with a ::value member have
a _v alias which reduces verbosity. Or on other words
std::is_integral<T>::value
can be replaced with
std::is_integral_v<T>
Make this substitution throughout the code base. In places where gem5
introduced it's own similar templates, add a V alias, spelled
differently to match gem5's internal style.
gem5: :IsVarArgs<T>::value => gem5::IsVarArgsV<T>
Change-Id: I1d84ffc4a236ad699471569e7916ec17fe5f109a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48604
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
When clone is called with the VFORK flag, the calling process is
suspended until the child process either exits, or calls execve.
This patch adds in a new variable to Process, which is used to store the
context of the calling process if this process is created through a
clone with VFORK set.
This patch also adds the required support in clone to suspend the
calling thread, and in exitImpl and execveFunc to wake up the calling
thread when the child thread calls either of those functions
Change-Id: I85af67544ea1d5df7102dcff1331b5a6f6f4fa7c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48346
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
There were three things preventing execve from working
Firstly, the entrypoint for the new program wasn't correct. This was
fixed by calling Process::init, which adds a bias to the entrypoint.
Secondly, the uname string wasn't being copied over. This meant when the
new executable tried to run, it would think the kernel was too old to
run on, and would error out. This was fixed by copying over the uname
string (the `release` string in Process) when creating the new process.
Additionally, this patch also ensures we copy over the uname string in
the clone implementation, as otherwise a cloned thread that called
execve would crash.
Finally, we choose to not delete the new ProcessParams or the old
Process. This is done both because it matches what is done in cloneFunc,
but also because deleting the old process results in a segfault later
on.
Change-Id: I4ca201da689e9e37671b4cb477dc76fa12eecf69
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48345
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The proxies are not used on the critical path, and it's usually implicit
whether they should be the FS or SE version.
Ideally in the future we won't need to worry about which version we need
to use, but the differences haven't quite been abstracted away, and
occasionally we need to decide between the two.
Change-Id: Idb363d6ddc681f7c1ad5e7aba69865f40aa30dc8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45907
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.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>
sched_getaffinity is different from other syscalls in the raw syscall
return the size of the cpumask being used to represent the CPU bit mask.
Because of this, when a library (libnuma in this case) directly called
sched_getaffinity and got a return value of 0, it errored out, thinking
that there were no CPUs available.
This implementation assumes that all CPUs are available, so it sets
all simulated CPUs in the bitmask
Change-Id: Id95c919986cc98a411877056256604f57a29f0f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46243
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Add serialization of the fd array when checkpointing in SE mode.
With this patch, host backed files are restored.
Further work needs to be done for restoring other types of
file descriptor.
As the file path saved is relative, on restoration of the checkpoint,
it may fail to open the file if the path is no longer valid.
If it cannot open the file, it will exit the simulation
with a meaningful error message.
Change-Id: I4d0c7cd614a8abaffcae9aba1a28c9fdbc023c5a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46619
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously Serializable::serializeAll called SimObject::
serializeAll. This created an unnecessary dependency. This
change makes Serializable responsible for the generation
of the checkpoint file, and then the SimObjects will
perform the serialization of the object using that file.
With this change serialize.hh contains only functions
related to the (un)serialization of basic types or
objects that inherit from Serializable. As a general
rule, functions related to the (un)serialization of
specific/other types must be defined in the file that
introduces that type.
Change-Id: I9438b799d7e9d4c992a62c7f9d1f15f3f3250a5a
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38740
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
SimObjects keep a static list with all existing
SimObjects. This list is then used to serialize
all objects declared in the system. If these
macros were used then an object would be serialized
more than once, which is not a correct behavior.
Change-Id: Idc4433ec2a23a21ee5ee2b7cc2facfe3dd979859
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46720
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
With this change serialize.hh is no longer responsible
for the (un)serialization of events. As a general rule,
rules to (un)serialize non-basic types should be defined
at the file that introduces that type. Therefore,
(UN)SERIALIZE_EVENT have been moved to eventq.hh.
Globals has a single instance which must be serialized
and unserialized. Instead of having a stray global
variable handled by Serialization, we pass its management
to Root. As a side effect, Globals is assigned its own
files: sim/globals.(cc/hh).
Finally, 'unserializeGlobals()' is removed, so that
Root can fully handle Globals' serialization. This
breaks checkpoint compatibility, so a checkpoint
upgrader is added.
Change-Id: I9c8e57306f83f9cc30ab2b745a4972755191bec4
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43586
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.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>
