| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Having them implicitly is apparently deprecated and throws a warning
in gcc 9, breaking the build.
Change-Id: Id4e3074966d1ffc6dd1aed9397de5eea84400027
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24926
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This commit moves the initCPU calls from initState to init
of base cpu (which were added in commit 0b8d02dec492215aa).
This is a temporary fix to solve the problem of X86System
initState getting called before initState of base cpu.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-292
Change-Id: I7434cd811536175562cfa2646f4326907fadad8c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24884
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.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>
|
|
https://gem5-review.googlesource.com/c/public/gem5/+/19173 did the same
for MinorCPU
Change-Id: I22d631a3d2032570f6e84b0f5eb018d1f84414ef
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23952
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This is aligning with MinorCPU, where an enum is tagging a Full, Partial
and No address coverage.
Change-Id: I0e0ba9b88c6f08c04430859e88135c61c56e6884
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23951
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.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>
|
|
Change-Id: I7cb50b80b70fcf43ab23eb9e7333d16328993fe1
Signed-off-by: Gabor Dozsa <gabor.dozsa@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19173
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This should be the interface to be used to check if the request
has some masked bytes.
JIRA: https://gem5.atlassian.net/browse/GEM5-196
Change-Id: I1ab5fd266c7b63a928aada32ae6d4f7fa915f2b6
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23523
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: I2206559c6c2a6e6a0452e9c7d9964792afa9f358
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23282
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
Those are already present in writeMem; looking for consistency
Change-Id: Ib85e0db228bc73e3ac64155d1290444cf6864a8c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23281
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
|
|
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>
|
|
This conditional compilation was unnecessary and makes gem5 more
brittle and harder to understand.
Change-Id: I63abaf2668252c988cdd4626ff6a462eb6f54b04
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22544
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The original motivation of this is to help debug syscall emulation
deadlocks.
Change-Id: I1c4f611fa2f2e464a30dc92baac89ca819e16a97
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21759
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
|
|
It doesn't matter if the bytes are converted before or after they're
fed into the decoder. The ISA already knows what endianness to use
implicitly, and this frees the CPU which doesn't from having to worry
about it.
Change-Id: Id6574ee81bbf4f032c1d7b2901a664f2bd014fbc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22343
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The c58cb8c9 changeset broke some code related to checking
consistency model guarantees (found in X86 benchmarks).
This changeset adds some documentation to the code and obviates
the problem.
Change-Id: Ied9c6b0b1d237538efe4beb2f97ef76248ce2746
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22283
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
|
|
This patch fixes the handling of memory order violations due to snoops
targeting out-of-order loads: the re-execution triggered in these cases
is achieved by raising a ReExec fault, but such a fault was not handled
correctly after the code changes introduced in changeset 46da8fb.
Change-Id: I2abe161a90468412f56cb28dcc92729326cba1cd
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21819
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Timothy Hayes <timothy.hayes@arm.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
This was only used by the KVM CPU, and it has access to all it needs to
figure out that value locally without requiring all the ThreadContexts
to implement an equivalent function.
Change-Id: I17a14ce669db2519edf129db761ebd8dc3bd4129
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22114
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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>
|
|
Also delete the CPU interface.
Change-Id: I62a6b0a9a303d672f4083bdedf393f9f6d07331f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22109
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>
|
|
This lets us move the event queue itself around, or change how those
services are provided.
Change-Id: Ie36665b353cf9788968f253cf281a854a6eff4f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22107
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The System keeps track of what events are live so new ThreadContexts
can have the same set of events as the other ThreadContexts.
Change-Id: Id22bfa0af7592a43d97be1564ca067b08ac1de7c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22106
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Both the thread and system's PCEventQueue are checked when appropriate.
Change-Id: I16c371339c91a37b5641860d974e546a30e23e13
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22105
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
These can now be built without referring to anything in ThreadContext
and so can be built even with the NULL ISA. This means the pcEventQueue
can be unconditionally built into the System class. Even though the
pcEventQueue is going away, this still makes it possible for System to
be a PCEventScope unconditionally.
Change-Id: Ia342bb7972b1b5ce95033176d72af4bfa343560f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22104
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This requires reaching into the threadcontext to access the CPU
pointer, and also isn't all that useful since it's more important what
event happened, not what CPU happened to be running the code at that
time.
Change-Id: I368707c804dff9bd349f3261bdcd08be55c5d04a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22103
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This prevents having to access it from within the ThreadContext.
Change-Id: I34f5815a11201b8fc41871c18bdbbcd0f40305cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22102
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
First of all, this would arbitrarily skip events based on when they
were encountered in the queue. Second, this is one of the three places
where the ThreadContext is actually accessed in pc_event.cc. By
removing this and the other uses, this file can be included even when
using the NULL ISA, and a lot of #ifdefs can be removed.
Change-Id: If81f5e9ff9d3f9833145fec0b6062b4bda8d2e47
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22100
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This abstraction will allow scheduling PCEvents for a particular
ThreadContext, all contexts on a CPU, all contexts in a system, etc.,
and delegates scheduling and removing events to each particular scope.
Right now the PCEventQueue is the only implementor of the PCEventSCope
interface.
Change-Id: I8fb62931511136229915c2e19d36aae7ffdec9df
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22099
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The TLBs now create the stage 2 MMUs as children, and since those are
specialized for instruction and data, the CPU needs to use ArmITB or
ArmDTB instead of ArmTLB which is the base class without an MMU. This
was changed for the BaseCPU and SimpleCPU checker already, but the TLBs
are added in the O3 checker CPU as well.
Change-Id: I498f247f376c8721fb70ce26c0f1b0815b12fe2d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22039
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The TLBs now create the stage 2 MMUs as children, and since those are
specialized for instruction and data, the CPU needs to use ArmITB or
ArmDTB instead of ArmTLB which is the base class without an MMU. This
was changed for the BaseCPU already, but the TLBs are added in the
checker CPU as well.
Change-Id: Ide8ce950622b40f69c37bbe2ea0d22295b76d7a6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21979
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This regularizes the TLB setup in the CPU so that ARM is no longer a
special case with extra objects.
Change-Id: I739b82578ff74f8f9777cd7e34cd5227b47b186c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21842
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
That abstracts the ISA further from the CPU, getting us a small step
closer to being able to build in more than one ISA at a time.
Change-Id: Ibf7e26a3df411ffe994ac1e11d2a53b656863223
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20831
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
These aren't referred to in the C++, so there's no reason for them to
be parameters. By making them children, they can still be modified,
replaced wholesale, or even replaced by an entirely different object
to, for instance, mask them when they're not needed.
Change-Id: Ic7f144a3cd3d1fca12fec220918aa72af885f61c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21839
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
The record_t typedef isn't all that helpful, and is also not consistent
with gem5 style. The map_t style is more useful but is also not
compliant. This change eliminates the first typedef and replaces the
second with a type called Map.
There are some other small style fixups added in as well, like making
the member variable pc_map pcMap.
Change-Id: I8ffea529004fd6d5b42fdc60250804e2e4987e88
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21781
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This was initially added in 2003 and only supported in the simple CPUs.
It's oddly specific since there are no other similar event queues for,
for instance, stores, branches, system calls, etc.
Given that this seems like a historical oddity which is only partially
supported and would be very hard to support on more diverse CPU types
like KVM or fast model which don't generally have hooks for counts of
specific instruction types.
Change-Id: I29209b7ffcf896cf424b71545c9c7546f439e2b9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21780
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Change-Id: I2adae2858897e665fd28cfe9de3fdcf95ffc2a2e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21779
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>
|
|
This queue was set up to allow triggering events based on the total
number of instructions executed at the system level, and was added in
a change which added a number of things to support McPAT. No code
checked into gem5 actually schedules an event on that queue, and no
code in McPAT (which seems to have gone dormant) either downloadable
from github or found in ext modify gem5 in a way that makes it use
the instEventQueue.
Also, the KVM CPU does not interact with the instEventQueue correctly.
While it does check the per-thread instruction event queue when
deciding how long to run, it does not check the instEventQueue. It will
poke it to run events when it stops for other reasons, but it may (and
likely will) have run beyond the point where it was supposed to stop.
Since this queue doesn't seem to actually be used for anything, isn't
being used properly in all cases anyway, and adds overhead to all the
CPU models, this change eliminates it.
Change-Id: I0e126df14788c37a6d58ca9e1bb2686b70e60d88
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21783
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Tiago Mück <tiago.muck@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
glibc 2.30 introduced the function gettid() in sys/types.h to return the
caller's thread ID. In order to avoid conflicts, the already present
gettid() functions have been renamed to sysGettid(). This fixes a
compilation error with X86 arch.
Change-Id: I76c971465fc4b50e4decde8303185439082b2378
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21379
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
Use the enum defined in the memory controller rather than custom
strings and int that are later converted to the DRAMCtrl::AddrMap
enum.
Change-Id: Ie5b19f915f9990fd2b7505d4d1b17b6fc2100f9e
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21080
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This change uses the params as instantiated from the default
constructor to create the checker cpu. If any of these parameters are
invalid for the checker cpu, the simulation will exit with a warning.
Change-Id: I0e58ed096c9ea5f413f2e9b64d8d184d9b0fc84e
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21079
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
This change is based on modify the way we move the AtomicOpFunctor*
through gem5 in order to mantain proper ownership of the object and
ensuring its destruction when it is no longer used.
Doing that we fix at the same time a memory leak in Request.hh
where we were assigning a new AtomicOpFunctor* without destroying the
previous one.
This change creates a new type AtomicOpFunctor_ptr as a
std::unique_ptr<AtomicOpFunctor> and move its ownership as needed. Except
for its only usage when AtomicOpFunc() is called.
Change-Id: Ic516f9d8217cb1ae1f0a19500e5da0336da9fd4f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20919
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
|
data_write_req byteEnable which is used in ARM SVE partial writes was not
being zeroed between writes.
As a result, non-SVE memory write instructions such as STP that followed
SVE memory write instructions could still have the write mask active.
This could lead to wrong simulation behaviour, and to an assertion failure:
src/mem/packet.hh:1211: void Packet::writeData(uint8_t*) const: Assertion
`req->getByteEnable().size() == getSize()' failed. '`
Change-Id: I74b5a82675e9923b0ffdf2c1dd9afb00c91cb204
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20448
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
|
