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>
Before this change, running:
./build/NULL/gem5.opt configs/example/ruby_mem_test.py -m 20000000 \
--functional 10
would only print warning for memory errors such as:
warn: Read access failed at 0x107a00
and there was no way to make the simulation fail.
This commit makes those warnings into errors such as:
panic: Read access failed at 0x107a00
unless --suppress-func-errors is given.
This will be used to automate MemTest testing in later commits.
Change-Id: I1840c1ed1853f1a71ec73bd50cadaac095794f91
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26804
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 components in base/loader were moved into a namespace called
Loader. This will make it easier to add loader components with fairly
short natural names which don't invite name collisions.
gem5 should use namespaces more in general for that reason and to make
it easier to write independent components without having to worry about
name collisions being added in the future.
Unfortunately this namespace has the same name as a class used to load
an object file into a process object. These names can be disambiguated
because the Process loader is inside the Process scope and the Loader
namespace is at global scope, but it's still confusing to read.
Fortunately, this shouldn't last for very long since the responsibility
for loading Processes is going to move to a fake OS object which will
expect to load a particular type of Process, for instance, fake 64 bit
x86 linux will load either 32 or 64 bit x86 processes.
That means that the capability to feed any binary that matches the
current build into gem5 and have gem5 figure out what to do with it
will likely be going away in the future. That's likely for the best,
since it will force users to be more explicit about what they're trying
to do, ie what OS they want to try to load a given binary, and also
will prevent loading two or more Processes which are for different OSes
to the same system, something that's possible today as far as I know
since there are no consistency checks.
Change-Id: Iea0012e98f39f5e20a7c351b78cdff9401f5e326
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24783
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This generalized Workload SimObject is not geared towards FS or SE
simulations, although currently it's only used in FS. This gets rid
of the ARM specific highestELIs64 property (from the workload, not the
system) and replaces it with a generic getArch.
The old globally accessible kernel symtab has been replaced with a
symtab accessor which takes a ThreadContext *. The parameter isn't used
for anything for now, but in cases where there might be multiple
symbol tables to choose from (kernel vs. current user space?) the
method will now be able to distinguish which to use. This also makes
it possible for the workload to manage its symbol table with whatever
policy makes sense for it.
That method returns a const SymbolTable * since most of the time the
symbol table doesn't need to be modified. In the one case where an
external entity needs to modify the table, two pseudo instructions,
the table to modify isn't necessarily the one that's currently active.
For instance, the pseudo instruction will likely execute in user space,
but might be intended to add a symbol to the kernel in case something
like a module was loaded.
To support that usage, the workload has a generic "insertSymbol" method
which will insert the symbol in the table that "makes sense". There is
a lot of ambiguity what that means, but it's no less ambiguous than
today where we're only saved by the fact that there is generally only
one active symbol table to worry about.
This change also introduces a KernelWorkload SimObject class which
inherits from Workload and adds in kernel related members for cases
where the kernel is specified in the config and loaded by gem5 itself.
That's the common case, but the base Workload class would be used
directly when, for instance, doing a baremetal simulation or if the
kernel is loaded by software within the simulation as is the case for
SPARC FS.
Because a given architecture specific workload class needs to inherit
from either Workload or KernelWorkload, this change removes the
ability to boot ARM without a kernel. This ability should be restored
in the future.
To make having or not having a kernel more flexible, the kernel
specific members of the KernelWorkload should be factored out into
their own object which can then be attached to a workload through a
(potentially unused) property rather than inheritance.
Change-Id: Idf72615260266d7b4478d20d4035ed5a1e7aa241
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24283
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Two python Enum parameter types had some very generic elements which
both include one named "none". When headers for both are included that
creates a conflict which breaks the build. Enums which such extremely
generic names need to be scoped so that they don't invite these sorts
of collisions.
This change converts them from Enum to ScopedEnum in python, and also
makes a few small changes to where they're used in c++ to match.
Issue-on: https://gem5.atlassian.net/browse/GEM5-447
Change-Id: Ibda6e6cfcd700a618f8c68d174f33ec1e178b9ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27950
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is another fix for the AArch32-AArch64 interprocessing issue
introduced in
3d15150d cpu, arch, arch-arm: Wire unused VecElem code in the O3 model.
Register mapping between AArch32 and AArch64 is explicitly defined in
ARMv8 manual. This allows software to read registers right after a state
switch without writing them first, and it is indeed common for software
to save registers to memory first before using them.
In gem5's implementation of vector mode switching, however, vectors may
not be marked as ready right after a state switch. Software reads toward
vectors at this time will stall O3CPU forever. This patch fixes this by
marking all mapped vectors (or vector elements, depending on AArch32 or
AArch64) as ready right after switching vector mode.
Change-Id: I609552c543dad8da66939c0a3079d73d48e92163
Signed-off-by: Hsuan Hsu <hsuan.hsu@mediatek.com>
Signed-off-by: Howard Wang <Howard.Wang@mediatek.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26203
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch extends the IntrControl to provided additional member
functions for (1) clearing all pending interrupts in a PE and (2)
checking for any pending interrupt in a PE. These are intended to
be used from interrupt management related peripherals.
Change-Id: I06b553872ed469e7449b872a0716865773ace154
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26809
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only functional difference between them was that the SE one might
have optionally fixed up missing translations for demand paging.
This lets us get rid of some code recreating the proxy ports in
setProcessPtr since the SE translating port no longer keeps a copy of
the process object pointer.
Change-Id: Id97df1874f1de138ffd4f2dbb5846dda79d9e4ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26550
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@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>
The version of vtophys which didn't take a ThreadContext had only been
implemented on Alpha which has since been removed, so this version of
the function was completely unimplemented and never used.
This change also gets rid of the dbg_vtophys which was sometimes
implemented but also never used, and takes the opportunity to fix up
some style problems in some of the vtophys arch files.
Change-Id: Ie10f881f8ce08c7188e71805357cf3264be4c81a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26224
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are only used in these two files, one each, and pass one dummy
argument with a default value and one extra argument with an actual
value compared to the more common constructors.
Instead, switch to constructors without those two arguments and set the
one extra value explicitly after construction.
The constructor will likely be inlined, and merged with this additional
assignment.
Change-Id: I75ca539d5ca95b57b4f4322ffa050af2031544dd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26229
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
The new local access mechanism installs a callback in the request which
implements what the mmapped IPR was doing. That avoids having to have
stubs in ISAs that don't have mmapped IPRs, avoids having to encode
what to do to communicate from the TLB and the mmapped IPR functions,
and gets rid of another global ISA interface function and header files.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I772c2ae2ca3830a4486919ce9804560c0f2d596a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23188
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch fixes the AArch32-AArch64 interprocessing issue introduced in
3d15150d cpu, arch, arch-arm: Wire unused VecElem code in the O3 model.
When O3CPU switches vector renaming mode, architectural-physical mapping
and physical free list are switched in the following way so that content
of vectors has no change from software view:
Case 1. Full mode -> Elem mode (AArch64 -> AArch32):
1.1. Split vector-vector mapping into element-element mapping.
1.2. Split vectors in free list into elements.
Case 2. Elem mode -> Full mode (AArch32 -> AArch64):
2.1. Move content of all N*M mapped physical elements to first N*M
physical elements in architectural order (N = number of
architectural vectors, M = number of elements per vector).
2.2. Map N architectural vectors to first N physical vectors (i.e.
initial mapping in full mode).
2.3. Place remaining physical vectors in free list (i.e. initial free
list in full mode).
Previous gem5 revision misses step 2.2 when AArch32->AArch64 switch.
The wrong mapping will lead to the situation in which a physical vector
is assigned twice to a same architectural vector without being freed.
Once this occurs, the physical vector will not be freed anymore, since
it is treated as a special register (e.g. zero or misc) by O3CPU's
renaming logic. Eventually O3CPU will either stall forever when all
physical vectors get stuck, or trigger the panic condition "The free
list has lost vector registers" when AArch64->AArch32 switch. This patch
adds the missing step and fixes the issue.
Change-Id: I32233635c28763260bcbb776b52ed198a9abace9
Signed-off-by: Hsuan Hsu <hsuan.hsu@mediatek.com>
Signed-off-by: Howard Wang <Howard.Wang@mediatek.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25743
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is mostly only a superficial change since the isa parameter is
then dynamic cast to the ISA specific version inside the various
consumers, currently the SimpleThread, O3CPU and Decoder classes. If
those aren't being used, for instance in the fast model CPUs, then you
can use a different ISA implementation without any type clashes.
Change-Id: I2226ef60f9a471ae51b8bfce8683033f7854197a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25009
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The call to initCPU was moved into initState in the base CPU class
since it should only really be called when starting a simulation
fresh. Otherwise checkpointed state will be loaded over the state of
the CPU anyway, so there's no reason to set up anything else.
Unfortunately that made it possible for the System level initialization
and the CPU initialization to happen out of order, effectively letting
initCPU clobber the state the System might have set up to prepare for
executing a kernel for instance.
To work around that issue, the call was moved to init which would
necessarily happen before initState, restoring the original ordering.
This change moves the change *back* into initState, but of the System
class instead of the CPU class. This makes it possible to guarantee
that OS initialization happens after initCPU since that's also done
by System subclasses, and they control when they call initCPU of the
base class.
This also slightly simmplifies when initCPU is called since we
shouldn't need to check whether a context is switched out or not. If
it's registered with the System object, then it should be in a
currently swapped in CPU.
This also puts the initCPU and startupCPU calls right next to each
other. A future change will take advantage of that and merge the
calls together.
Also, because there are already ISA specific subclasses of System
which already have specialized versions of initState, we should be
able to move the code in initCPU and startupCPU directly into those
subclasses. That will give those subclasses more flexibilty if, for
instance, they want all CPUs to start running in the BIOS like they
would on a real system, or if they want only the BSP to be active
as if the BIOS had already paused the APs before passing control to
a bootloader or OS.
This will also remove another two TheISA:: style functions, reducing
the number of global dependencies on a single ISA.
Change-Id: Ic56924660a5b575a07844a198f69a0e7fa212b52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24903
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A recent-ish change modified ExeTraceRecord::traceInst to make it more
consistent with DPRINTF-s by using dprintf_flag to print the trace
string. The generated string was passed as the format however, and that
means that all % characters in the output (from register names, for
example) are interpreted as format characters, mangling the output and
making cprintf angry since there are no corresponding arguments.
This change sets the format to "%s" instead, and passes the trace
string as the first argument. The argument won't be parsed for format
specifiers, and so should no longer get mangled.
Change-Id: I8fa9c2c22179a5b55104a618a4af4080a3931c5f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24643
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
TheISA::initCPU is basically an ISA specific implementation of reset
logic on architectural state. As such, it only needs to be called if
we're not going to load a checkpoint, ie in initState.
Also, since the implementation was the same across all CPUs, this
change collapses all the individual implementations down into the base
CPU class.
Change-Id: Id68133fd7f31619c90bf7b3aad35ae20871acaa4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24189
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
The code block was relying on passed_predicate only (conditional
execution). This was not covering the case where the instruction
gets executed, but the predicate register is false. Using the inLSQ
variable is covering both cases and it makes more sense in terms of
readibility.
Change-Id: Ie1954f37968379a5bda9d0dc9f824a68304cc229
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23280
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The logic that determines which syscall to call was built into the
implementation of faults/exceptions or even into the instruction
decoder, but that logic can depend on what OS is being used, and
sometimes even what version, for example 32bit vs. 64bit.
This change pushes that logic up into the Process objects since those
already handle a lot of the aspects of emulating the guest OS. Instead,
the ISA or fault implementations just notify the rest of the system
that a nebulous syscall has happened, and that gets propogated upward
until the process does something with it. That's very analogous to how
a system call would work on a real machine.
When a system call happens, the low level component which detects that
should call tc->syscall(&fault), where tc is the relevant thread (or
execution) context, and fault is a Fault which can ultimately be set
by the system call implementation.
The TC implementor (probably a CPU) will then have a chance to do
whatever it needs to to handle a system call. Currently only O3 does
anything special here. That implementor will end up calling the
Process's syscall() method.
Once in Process::syscall, the process object will use it's contextual
knowledge to determine what system call is being requested. It then
calls Process::doSyscall with the right syscall number, where doSyscall
centralizes the common mechanism for actually retrieving and calling
into the system call implementation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I937ec1ef0576142c2a182ff33ca508d77ad0e7a1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23176
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
There is a check on a global flag denoting that the simulator
has been configured to run in fullsystem mode. The check is
conducted at runtime during calls to syscall methods.
The high-level models are checking the flag when the check
could be conducted further down the call chain (nearer to the
actual Process invocation). Moving the checks should result
in less copy-pasta as new models are developed. It might be
argued that the checks should stay in place since an error
would detected earlier; that may be true, but the error
would be the same and the simulation should fail in either
case. This arrangement requires fewer lines of code.
The changeset also changes the check into a fatal error
instead of a panic since usage (in fs mode) should result
in immediate corruption.
Change-Id: If387e27f166ac1374f3fe8b7befe3546e69adba7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23240
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The trace mechanism appears to be the only debug flag that does not
go through DPRINTF, presumably for performance reasons.
This patch manually adds that to make things uniform with other debug
flags, e.g. with FmtFlag,ExecAll,SyscallBase a sample output looks like
(truncated to fit into commit message lengths):
0: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue
500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+4
1000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+8
1500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+12
2000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+16
2500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+20
3000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+24
3500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+28
Change-Id: Ic371ebc8b0827656f1b78fcfd3f28505a5100274
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22007
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If FmtTicksOff is given, ticks are disabled for all log messages.
The original motivation of this is to bring the implementation of native
traces closer to that of other traces to help refactoring done in future
patches.
One additional advantage of this is that sometimes we want to compare
traces of a given program under different conditions, so the start of the
ROI is different, and the different initial timestamp makes a diff
useless by showing differences on every line.
Change-Id: Idd6cb105d301b3b9b064996043f4ca75ddafe0af
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22006
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
