Before this commit:
* SEV events were not waking neither WFE (wrong) nor futex WAIT (correct)
* locked memory events (LLSC) due to LDXR and STXR were waking up both
WFE (correct) and futex WAIT (wrong)
This commit fixes all wrong behaviours mentioned above.
The fact that LLSC events were waking up futexes leads to deadlocks,
as shown in the test case described at:
https://gem5.atlassian.net/browse/GEM5-537
because threads woken up by SVE are not removed from the waiter list
for the futex address they are sleeping on.
A previous fix atttempt was done at:
1531b56d605d47252dc0620bb3e755b7cf84df97
in which only sleeping threads are woken up. But that is not sufficient,
because the futex sleeping thread that was being wrongly woken up on SEV
can start to sleep on a second futex.
As an example, consider the case where 4 threads are fighting over two
critical sections protected by futex1 and futex2 addresses. In this case,
one thread wakes up the other thread after it is done with the section.
Suppose the following sequence of events:
* thread1 is awake and all others are suspended on futex1
* thread1 SEV wakes thread2 from the futex1 while in the critical region 1.
This is the wrong behaviour that this patch prevents, because
now thread2 is still in the sleeper list for futex1
* thread1 then futex wakes tread3, then proceeds to critical region 2.
* thread3 wakes up, but because thread2 has critical region, it sleeps
again.
* thread2 finishes its work, futex wakes thread3, and then proceeds to
futex2
When it reaches futex2, thread1 is still working there, so it sleeps on
futex2.
* thread3 futex wakes thread2, because it is still wrongly on the sleeper
list of futex1. But thread2 is in futex2 now.
If it weren't for this mistake, it should have awaken the final thread4
instead.
Outcome: thread4 sleeps forever, no other thread ever wakes it, because all
other threads have woken from futex1 and awoken another thread.
The problem is fixed by adding the waitingTcs unordered_set FutexMap,
which is basically an inverse map to FutexMap, which tracks (addr,
tgid) -> ThreadContext. This allows us allow to quickly check
if a given ThreadContext is waiting on a futex in any address.
Then the SEV wakeup code path
now checks if the thread is k
Change-Id: Icec5e30b041f53e5aa3b6e0d291e77bc0e865984
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29777
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Both methods do basically the same, especially since they don't handle the
timeout which is basically the only difference between both modes of the
syscall (one uses absolute and the other relative time).
Remove the WaiterState::WaiterState(ThreadContext* _tc) constructor,
since the only calls were from FutexMap::suspend which does not use them
anymore. Instead, set the magic 0xffffffff constant as a parameter to
suspend_bitset.
Change-Id: I69d86bad31d63604657a3c71cf07e5623f0ea639
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29776
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add checkpoint parameters (together with corresponding serialization
and unserialization) for VMA list of class MemState into a separate
section named 'vmalist'.
Without these VMA list parameters, a page table fault will occur when
running with --restore-simpoint-checkpoint, because of an empty VMA
list. For example:
$ ./build/RISCV/gem5.debug --debug-flags=Exec configs/example/se.py \
-c tests/test-progs/hello/bin/riscv/linux/hello \
--cpu-type=NonCachingSimpleCPU --restore-simpoint-checkpoint \
--checkpoint-dir m5out/ -r 2
...
2404000: system.switch_cpus: T0 : @_int_malloc+3392 : sd a5, 8(a0) \
: MemWrite : D=0x000000000001ed21 A=0x862e8
panic: Page table fault when accessing virtual address 0x862e8
...
Example checkpoint output:
[system.cpu.workload.vmalist]
size=3
[system.cpu.workload.vmalist.Vma0]
name=stack
addrRangeStart=...
addrRangeEnd=...
[system.cpu.workload.vmalist.Vma1]
name=heap
addrRangeStart=...
addrRangeEnd=...
[system.cpu.workload.vmalist.Vma2]
...
Change-Id: Ib2fa7ad2c34fe667ce95bc4b10a1affcf60d9c1f
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31875
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This very simple and mostly useless operation has no side effects, and
can be used to verify that arguments are making it into gem5, being
operated on, and then that a result can be returned into the simulation.
Change-Id: I29bce824078526ff77513c80365f8fad88fef128
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27557
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.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>
This patch adds a faulting flag to InstRecord.
This allows tracers to identify that the traced instruction has
faulted, when ExecFaulting is enabled. It can be set with
InstRecord::setFaulting() and read with Instrecord::getFaulting().
Change-Id: I390392d59de930533eab101e96dc4d3c76500748
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30134
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Initialize _stackSize and _stackMin to the maximum stack size values.
The are setup in each arch's Process::initState and may be uninitialized
until then. If a stack fixup occurs before these are setup, addresses
which are not in the stack might be allocated on the stack. This
prevents that until they are initialized in Process::initState. If an
access occurs before that with these initial values, the stack fixup
will simply allocate a page of memory in the stack space. However, it
will not print the typical info messages about growing the stack during
this time.
Change-Id: I9f9316734f4bf1f773fc538922e83b867731c684
JIRA: https://gem5.atlassian.net/browse/GEM5-629
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30394
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are the stats in the base class, not in any derived classes. Only
Alpha has an additional stats. These were not really "kernel"
statistics, they were just applicable primarily in FS. They are
potentially applicable to any simulation, but will probably not be
incremented in SE simulations.
Also this merges these stats from being per thread to being per
workload, ie operating system instance. This is probably more relevant
since exactly what thread within a workload runs which particular
instruction is not very important/predictable, but the aggregate
behavior is. If necessary, this could be adjusted in the future to
split things back out again into stats per thread while keeping them
inside the single workload object.
Change-Id: I130e11a9022bdfcadcfb02c7995871503114cd53
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25147
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If a port is unbound, trying to call its peer will likely cause a
segfault. Rather than check if a port is bound every time you go to use
it, we can instead bind to a default peer which just throws an exception
back to the caller. The caller can catch the exception and report the
error.
This change adds a common new class to throw as the exception, and also
a small utility function which reports the error and dies.
Change-Id: Ia58a2030922c73e2fd7d139822bce38d9b0f2171
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30295
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.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>
Instead of calling into object files after the fact and asking them to
put symbols into a target symbol table, this change makes object files
fill in a symbol table themselves at construction. Then, that table can
be retrieved and used to fill in aggregate tables, masked, moved,
and/or filtered to have only one type of symbol binding.
This simplifies the symbol management API of the object file types
significantly, and makes it easier to deal with symbol tables alongside
binaries in the FS workload classes.
Change-Id: Ic9006ca432033d72589867c93d9c5f8a1d87f73c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24787
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
All other considerations aside, DTRACE probably fits best in trace.hh
where it is now, but unfortunately that creates an awkward dependence
between that file and eventq.hh and eventq_impl.hh. DTRACE only depends
on flags in the Debug namespace and a universal macro TRACING_ON, so
even though it won't be alongside the things it's most logically
associated with, it will be alongside all of its dependencies.
An alternative would be to re-implement DTRACE in eventq_impl.hh which
wouldn't be too big of a problem because it's so simple, but it's
cleaner and less error prone to still keep a single definition.
Because base/trace.hh includes base/debug.hh, any consumers expecting to
find DTRACE in base/trace.hh will still get that definition, even though
it's no longer direct.
Change-Id: I0dac83295891630686c3a8038eb54138cf40ab44
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29411
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This uses a "name()" method which is not defined by the Ticked class,
and isn't a global method. This was probably originally supposed to be
the name() method of the Serializable class that Ticked inherits from,
but a while ago that was removed. It's not clear how this has been
compiling.
Instead, use the name() method of the ClockedObject which is the first
constructor argument.
Change-Id: Icfb71732c58ea9984ef7343bbaa46097a25abf28
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29406
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This constant isn't in normalized units, ie doesn't scale when the time
value of a Tick changes, is global, has an extremely generic name even
though it's only used by a few ethernet devices, and has an arbitrary
value.
Get rid of it, and replace it with 1ns, what it would typically be
equivalent to when using the default 1ps time scale.
Change-Id: I31d9dad438f854b4152cd53c9a7042a25d13e0a6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29398
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This singleton object is used thruoughout the simulator. There is
really no reason not to have it statically allocated, except that
whether it was allocated seems to sometimes be used as a signal that
something already put symbols in it, specifically in SE mode.
To keep that functionality for the moment, this change adds an "empty"
method to the SymbolTable class to make it easy to check if the symbol
table is empty, or if someone already populated it.
Change-Id: Ia93510082d3f9809fc504bc5803254d8c308d572
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24785
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SymbolTable class had been tracking symbols as two independent
pieces, a name and an address, and acted as a way to translate between
them. Symbols can be more complex than that, and so this change
encapsulates the information associated with a symbol in a new class.
As a step towards simplifying the API for reading symbols from a
binary, this change also adds a "binding" field to that class so that
global, local and weak symbols can all go in the same table and be
differentiated later as needed. That should unify the current API
which has a method for each symbol type.
While the innards of SymbolTable were being reworked, this change
also makes that class more STL like by adding iterators, and begin
and end methods. These iterate over a new vector which holds all the
symbols. The address and name keyed maps now hold indexes into that
vector instead of the other half of the symbol.
Change-Id: I8084f86fd737f697ec041bac86a635a315fd1194
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24784
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In the base Result and Argument templates, there were private static
functions which weren't meant to be used, but which would act as
documentation for what those functions should look like. They were
marked as private to prevent them from being accidentally used and
causing confusing, hard to debug errors.
Unfortunately, that also meant that those functions exist, and
apparently cause inconsistent problems with SFINAE. I assume if the
functions don't exist at all, then SFINAE will work properly. When
they're private, that seems to cause a substitution failure which
actually is an error which makes the build fail.
Change-Id: I326e9e1d05eafe1b00732ae10264354b07426e74
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28308
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If m5writeFile opens stdout/stderr, no file is registered in
OutputDirectory and thus we don't want to search for it on close.
In order to write multiple times to stdout/stderr in a reasonable way,
we also want to prevent seeking. Thus, don't seek if the offset is 0, in
which case this would be a noop anyway (we just opened the file without
append).
Finally, it is helpful for debugging if the stream is flushed on every
write.
Change-Id: I102f82dcd2c63420b6f3fe55d67f03c62349e69d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28727
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Sometimes when using the GuestABI mechanism, gem5 wants to know that a
function was called and with what arguments to do its own processing,
but doesn't want to return its own value since it will still let the
simulated system execute its own function. There are also situations
where gem5 wants to return a value, but not through the normal
mechanism. That happens when, for instance, a gem5 op is triggered by a
memory access, and that access is what should return the value, not a
particular fixed register.
This option is a template parameter rather than a function argument so
that if it's not going to be used, no "Return" type needs to be defined
since it's not present at all in the chain of functions invokeSimcall
expands to.
This will also make it easier to reuse generic ABIs in those situations
without having to make custom wrappers.
Change-Id: I969e78495c8f4e73f4de1a3dfb4d74c9b30f5af5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28288
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
PowerDomains group multiple objects together to regulate their power
state. There are 2 types of objects in a PowerDomain: leaders and
followers. The power state of a PowerDomain is the most performant
power state of any of the leaders. The power state of the followers is
determined by the power state of the PowerDomain they belong to: they
need to be in a power state which is more or equally performant to the
power state of the PowerDomain.
Leaders can be ClockedObjects or other PowerDomains. Followers can
only be ClockedObjects. PowerDomains can be be nested but a
PowerDomain can only be a leader of another PowerDomain, NOT a
follower. PowerDomains are not present in the hierarchy by default,
the user needs to create and configure them in the configuration file.
The user can add an hierachy by setting the led_by parameter. gem5
will then create leaders and followers for each domain and calculate
the allowed power states for the domain.
Objects in a PowerDomain need to have at least the ON state in the
possible_states.
An example of a powerDomain config is:
pd = PowerDomain()
cpu0 = BaseCPU()
cpu1 = BaseCPU()
shared_cache = BaseCache()
cache.power_state.led_by = pd
pd.led_by = [cpu0, cpu1]
This will create a PowerDomain, where the CPUs determine their own
power states and the shared cache (via the PowerDomain) follows those
power states (when possible).
Change-Id: I4c4cd01f06d45476c6e0fb2afeb778613733e2ff
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28051
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit adds the concept of possible power states to the
PowerState SimObject. This is a list of the power states a specific
object can be in. Before transitioning to a power state, a PowerState
object will first check if the requested power states is actually an
allowed state. The user can restricted the power states a
ClockedObject can go to during configuration. In addition, this change
sets the power states, a CPU can be in.
Change-Id: Ida414a87554a14f09767a272b54b5d19bfc8e911
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28050
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit does not make any functional changes but just rearranges
the existing code with regard to the power states. Previously, all
code regarding power states was in the ClockedObjects. However, it
seems more logical and cleaner to move this code into a separate
class, called PowerState. The PowerState is a now SimObject. Every
ClockedObject has a PowerState but this patch also allows for objects
with PowerState which are not ClockedObjects.
Change-Id: Id2db86dc14f140dc9d0912a8a7de237b9df9120d
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28049
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
