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 thermal models currently work on temperatures in Celsius stored in
plain doubles. Switch to using Temperature instead and internal
processing in Kelvin. There should be no impact on the result since
all thermal processes work on temperature deltas.
Change-Id: I22d0261ae102f30d86051f24a2d88b067b321c91
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39455
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I797163c8690ae0092e00e371d75f5e7cebbcd1f5
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39579
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When running multithreaded programs in SE-mode with DerivO3CPU model,
there are cases that two or more cores have page faults on the same page
in nearby ticks (can be at the same tick) when fetching instructions
(more likely) or accessing data. When these cores try come to the commit
stage in nearby ticks/cycles, they will try to handle the faults
(without clobbering). Then the first core will ask for a physical page
frame to map with the virtual page. In the previous version, the right
next core that tries to handle the fault will hit a panic condition in
the EmulationPageTable::map(...) as the page has been mapped and this
page fault is not to clobber the existing mapping.
In this changeset, if it is found that the page has been mapped and it
is not to clobber the existing mapping, it will return without further
mapping activities as the page fault has been handled previously.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-798
Change-Id: I9bb1163f9d1379c6fed9725101e4400fefdc8079
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39515
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 warning happens when a key is present in the checkpoint but not in the
values that gem5 source code knows about.
To do this, we must expose iteration over IniFile section keys. To not
have to make those classes public, a visitor method is implemented.
Change-Id: I23340a953f3e604642b97690a7328b10fdd740a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37575
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the name of the stats group of thr Root object is
Stats, which is likely to be confused with the Stats namespace.
This commit renames the struct to RootStats. This allows the
Stats namespace to be expressed as `Stats::`, which is
consistent with how the namespace is accessed in other part of
gem5.
Change-Id: Ieb425c3df1f5c0d5f11b1a467a36b2e0e07b2771
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38915
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The original implementation of curTick used a thread local variable,
_curEventQueue, and its getCurTick() method, to retrieve the curTick for
the currently active event queue. That meant that core.hh needed to
include eventq.hh so that the EventQueue type was available, which also
indirectly brought in a lot of other dependencies.
Unfortunately this couldn't easily be fixed by making curTick()
non-inline since this added a significant amount of overhead when
tested.
Instead, this change makes the code in core.hh/core.cc keep a pointer
directly to a Tick. The code which sets _curEventQueue now also sets
that pointer when _curEventQueue changes.
The way curTick() now reaches into the guts of the current EventQueue
directly is not great from a modularity perspective, but if curTick is
considered an extension of the EventQueue, then it's just odd that this
part is broken out into a different file.
Change-Id: I8341b40fe75e90672eb1d70e1a368975fcbfe926
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38996
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
When a gem5 op is triggered using a KVM MMIO exit event, the PC has
already been advanced beyond the offending instruction. Normally when
a system call or gem5 op is triggered, the PC has not advanced because
the instruction hasn't actually finished executing. This means that if
a gem5 op, and by extension a system call in SE mode, want to advance
the PC to the instruction after the gem5 op, they have to check whether
they were triggered from KVM.
To avoid having to special case these sorts of situations (currently
only in the clone system call), we can have the code which dispatches to
gem5 ops from KVM adjust the next PC so that it points to what the
current PC is. That way the PC can be advanced unconditionally, and will
point to the instruction after the one that triggered the call.
To be fully consistent, we would also need to adjust the current PC.
That would be non-trivial since we'd have to figure out where the
current instruction started, and that may not even be possible to
unambiguously determine given x86's instruction structure. Then we would
also need to restore the original PC to avoid confusing KVM.
Change-Id: I9ef90b2df8e27334dedc25c59eb45757f7220eea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38486
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These pseudo insts are less useful outside of full system, but they
should all still work. Removing this check makes it possible to, for
instance, test them in syscall emulation mode, and removes another
difference between the two styles of simulation.
Change-Id: Ia7d29bfc6f7c5c236045d151930fc171a6966799
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38485
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Since this class has a custom destructor ~ProbeListener(), it should
also generally have the 4 other methods defined, otherwise calling
those methods lead to subtle failures.
In this specific case, the ProbeManager *const manager; field stores a
pointer back to the ProbeListener object at:
ProbeListener::ProbeListener {
manager->addListener(name, *this);
which gets unregistered by the destructor:
ProbeListener::~ProbeListener()
manager->removeListener(name, *this);
and because the default copy does not re-register anything, it leads to
unregistration.
Therefore, a copy constructor would need the manager to support multiple
identical listeners, or at least refcount them, which would be overkill.
The two move operations would be more feasible, as we could make them
unregister the old ProbeListener address and then re-register the new one,
but that is not very efficient, so we just delete them as well.
A consequence of not implementing the move methods is that it is
impossible to store ProbeListener inside an std::vector. since objects
inside std::vector may need to be moved in memory when the vector resizes,
and therefore need to be movable. The alternative is to use an std::vector
of std::unique_ptr instead.
Change-Id: I8dc0157665391f86e2ca81d144bc6a42e9312d6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37977
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In clang, the following error was given:
```
In file included from build/X86/sim/eventq.hh:51:
build/X86/sim/serialize.hh:533:19: error: 'ScopedCheckpointSection' is a protected member of 'Serializable'
Serializable::ScopedCheckpointSection sec(os, sectionName);
^
build/X86/sim/serialize.hh:175:11: note: declared protected here
class ScopedCheckpointSection {
^
```
The use, at line 533, was introduced in this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/36135
This can be fixed by making ScopedCheckpointSection public.
Change-Id: Ib6ffba18d5e8c37980d4febb548f2405cb45ce8c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37915
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Inside the code of cloneFunc(…) //syscall_emul.hh
cp->initState(); //line 1483
p->clone(tc, ctc, cp, flags); //line 1484
…
ctc->clearArchRegs(); //line 1503
OS::archClone(flags, p, cp, tc, ctc, newStack, tlsPtr); //line 1505
…
At line 1483, initState() is called and the activateContext() of the
corresponding MinorCPU is eventually called. The actual architecture
clone happens at line 1505 where PC of the new thread could have a
correct value.
In the existing implementation of MinorCPU::activateContext(ThreadID
thread_id), the below line 275 is called
pipeline->wakeupFetch(thread_id);
to start fetching instruction with current value of PC, which is 0x0,
leading to panic “Page table fault when accessing virtual address 0”.
This is because the OS::archClone() is not yet called. So, the below bug
fix handles the wakeup fetch for a thread for two scenarios:
...
if (!threads[thread_id]->getUseForClone())
{ //the thread is not cloned
pipeline->wakeupFetch(thread_id);
} else {//the thread from clone
if (fetchEventWrapper != NULL)
delete fetchEventWrapper;
fetchEventWrapper = new EventFunctionWrapper([this, thread_id]
{pipeline->wakeupFetch(thread_id);}, "wakeupFetch");
schedule(*fetchEventWrapper, clockEdge(Cycles(0)));
}
...
If a thread is not cloned, pipeline->wakeupFetch() is called
immediately.
For the cloned thread, the above bug fix delays the execution of
pipeline->wakeupFetch()
after the OS::archClone is done. ThreadContext::getUseForClone() return
true if a thread is cloned.
A member variable fetchEventWrapper is added to MinorCPU class for
delayed fetch event.
A member variable useForClone and its corresponding get/set methods are
added to ThreadContext class. This approach allows future reuse of this
useForClone variable by other CPU models if needed and also avoid lots
of changes resulted by modifying parameters of activateContext () and
activate() which are defined as override.
Inside the syscall cloneFunc, the useForClone member of a ThreadContext
object is set via its set method right before Process's initState() is
called, shown as below.
ctc->setUseForClone(true);
cp->initState();
p->clone(tc, ctc, cp, flags);
A few previously failed RISC-V ASM tests have been open in tests.py file
after the bug fix works.
JIRA issue: https://gem5.atlassian.net/browse/GEM5-374
Change-Id: Ibffe46522e2617443d29f49df180692c54830f14
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37315
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The event in KVM x86 SE mode plays double duty, triggering a system call
or a page fault depending on where it's called from (the system call
handler vs page fault handler).
This means we can eliminate the page fault gem5 op and the
pseudo_inst.hh switching header file.
This change touches a lot of things, but there wasn't really a good
place to split it up which still made sense and was consistent and
functional.
Change-Id: Ic414829917bcbd421893aa6c89d78273e4926b78
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34165
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The *vast* majority of SimObjects use the standard boilerplate version
of their Params::create() method which just returns new
ClassName(*this); Rather than force every class to define this method,
or annoy and frustrate users who forget and then get linker errors, this
change automates the default while leaving the possibility of defining a
custom create() method for non-default cases.
The situations this mechanism handles can be first broken down by
whether the SimObject class has a constructor of the normal form, ie one
that takes a const Params reference as its only parameter.
If no, then no default create() implementation is defined, and one
*must* be defined by the user.
If yes, then a default create() implementation is defined as a weak
symbol. If the user still wants to define their own create method for
some reason, perhaps to add debugging info, to keep track of instances
in c++, etc., then they can and it will override the weak symbol and
take precedence.
The way this is implemented is not straightforward. A set of classes are
defined which use SFINAE which either map in the real Params type or a
dummy based on whether the normal constructor exists in the SimObject
class. Then those classes are used to define *a* create method.
Depending on how the SFINAE works out, that will either be *the* create
method on the real Params struct, or a create method on a dummy class
set up to just absorb the definition and then go away. In either case the
create() method is a weak symbol, but in the dummy case it
doesn't/shouldn't matter.
Annoyingly the compiler insists that the weak symbol be visible. While
that makes total sense normally, we don't actually care what happens to
the weak symbol if it's attached to the dummy class. Unfortunately that
means we need to make the dummy class globally visible, although we put
it in a namespace to keep it from colliding with anything useful.
Change-Id: I3767a8dc8dc03665a72d5e8c294550d96466f741
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35942
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is a way to send a very generic poke to the workload so it can do
something. It's up to the workload to know what information to look for
to interpret an event, such as what PC it came from, what register
values are, or the context of the workload itself (is this SE mode? which
OS is running?).
Change-Id: Ifa4bdf3b5c5a934338c50600747d0b65f4b5eb2b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34162
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The parseParam and showParam functions partially worked using template
specialization, and partially worked using function overloading. The
template specialization could be resolved later once other functions
were added, but the regular function overloads could not. That meant
that it was practically impossible to add new definitions of those two
functions local to the types they worked with.
Also, because C++ does not allow partial specialization of template
functions, it would not be possible to truly use specialization to wire
in BitUnion types.
To fix these problems, these functions have been turned into structs
which wrap static functions. These can be partially specialized as
desired, making them compatible with BitUnions. Also, it's not possible
to overload structures like it is with functions, so only specialization
is considered, not overloading.
While making these changes, these functions (now structs) were also
reworked so that they share implementation more, and are generally
more streamlined.
Given the fact that the previous parseParam and showParam functions
could not actually be expanded beyond serialize.hh, and were not
actually called directly by any code outside of that file, they should
have never been considered part of the API.
Now that these structs actually *can* be specialized outside of this
file, they should be considered part of the interface.
Change-Id: Ic8e677b97fda8378ee1da1f3cf6001e02783fde3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36280
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These had been written specifically for the vector, list, set, and C
style array types. This change reworks them to share an implementation,
and to work with more general types. The arrayParamOut method requires
std::begin() and std::end() to accept that type, and the arrayParamIn
method requires either insert or push_back, or the type to be an array.
Also fix up a couple of files which accidentally depended on includes in
the serialize headers which are no longer necessary.
Change-Id: I6ec4fe3bb900603bbb4e35c4efa620c249942452
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36277
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
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>
Global stats are currently exposed using the legacy stat system (i.e.,
without a parent group). This change moves global stats from
stat_control.cc to a group that gets exported from the Root object.
The implementation adds the Root::Stats class which has a single
global instance. This instance is exposed to the rest of the simulator
using the global rootStats symbol. The intention is that objects that
need global statistics in formulas access them through the rootStats
object.
The global names simSeconds, simTicks, simFreq, and hostSeconds are
now references to their respective members in the rootStats object.
Change-Id: I267b5244a0bcca93dd2dcf03388e7085bdd79c9e
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35616
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 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>
System calls should now be requested from the workload directly and not
routed through ExecContext or ThreadContext interfaces. That removes a
major special case for SE mode from those interfaces.
For now, when the SE workload gets a request for a system call, it
dispatches it to the appropriate Process object. In the future, the
ISA specific Workload subclasses will be responsible for handling system
calls and not the Process classes.
For simplicity, the Workload syscall() method is defined in the base
class but will panic everywhere except when SEWorkload overrides it. In
the future, this mechanism will turn into a way to request generic
services from the workload which are not necessarily system calls. For
instance, it could be a way to request handling of a page fault without
having to have another PseudoInst just for that purpose.
Change-Id: I18d36d64c54adf4f4f17a62e7e006ff2fc0b22f1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33282
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
