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>
An earlier change accidentally left out the actualTC-> prefix in the
getCurrentInstCount method which was supposed to delegate the call to
another thread context. Without that, it just called itself and would
infinitely recurse.
This bug was pointed out in email by Robert Henry.
Change-Id: Ibf1fee6b48ff87790309c6d435bd76fa95c6cab9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22623
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If the number of one of the register types is zero (useful on ARM in
the near future), memset will complain that it's given the length of
the array without multiplying by the size of the array elements. This
is a false positive since the length of the array and the number of
elements are both zero.
To avoid that warning/error and to simplify and update the SimpleThread
class slightly, this change replaces the C style arrays with
std::array.
Change-Id: Ifedd081a1940a578765c4d585e623236008ace67
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22523
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was useful when transitioning away from the CPU based
comInstEventQueue, but now that objects backing the ThreadContexts have
access to the underlying comInstEventQueue and can manipulate it
directly, they don't need to do so through a generic interface.
Getting rid of this function narrows and simplifies the interface.
Change-Id: I202d466d266551675ef6792d38c658d8a8f1cb8b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22113
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This switches to letting the ThreadContexts use a thread based/local
comInstEventQueue instead of falling back to the CPU's array. Because
the implementation is no longer shared and it's not given where the
comInstEventQueue (or other implementation) should be accessed, the
default implementation has been removed.
Also, because nobody is using the CPU's array of event queues, those
have been removed.
Change-Id: I515e6e00a2174067a928c33ef832bc5c840bdf7f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22110
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These then just use the comInstEventQueue array from the CPU, but soon
they will actually be self contained and allow the thread context to
use whatever mechanism it wants.
Also, now that the thread contexts need to exist before instruction
count based events can be scheduled, setting up max instruction based
events needs to happen in init after the CPU subclasses have had a
chance to set up the threadContexts vector.
Change-Id: I34bb401633d277a60be74e30d5a478a149b972ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22108
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
