Some AArch64 system registers report UNDEFINED behaviours if accessed
from EL2 or EL3 in a non-EL2 Host enabled (HCR_EL2.E2H == 0) environment.
Examples of these are seen in the Generic Timer system registers,
namely CNTP_CTL_EL02 or CNTKCTL_EL12.
This patch provides an ISA filter for specifying the above condition.
Change-Id: I240f9afdb000faf5d3c9274ba12bd4cc41fe8604
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24664
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These two functions were called in exactly one place one right after
the other, and served similar purposes.
This change merges them together, and cleans them up slightly. It also
removes checks for FullSystem, since those functions are only called
in full system to begin with.
Change-Id: I214f7d2d3f88960dccb5895c1241f61cd78716a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24904
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>
All of the state being checkpointed would either be provided by the
config directly, or would be brought into the TLB through normal fill
operations. Having this state in the checkpoint complicates the
checkpoint and significantly decreases compatibility with other TLB
implementations, or even variations of the same TLB, for instance if
the size was changed.
Change-Id: I4ea079dd01ff18fbc458b3aaaf88519dbcfdd869
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24389
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This doesn't actually change any behavior since RAX was being zeroed
anyway, but since we don't and almost certainly never will have a BIST
and the BIST is optional even in real hardware, we can drop it and
simplify initCPU a little further.
This reduces x86's initCPU function to just an invocation of
InitInterrupt's invoke.
Change-Id: I56b1aae2c1a738ef7ffabcf648dd7d0fb819d4e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24187
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The initCPU function was setting a lot of values to zero or other
initial values, but that's something the ISA object can do as part of
its clear() method. This gets rid of a lot of code that was
individually zeroing registers, and also centralizes responsibility
for those registers in the ISA.
Change-Id: Iafcffd3f9329c39f77009b38b1696f91c36c117e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24185
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The default constructor of the micropc enabled generic PCState class
set the next micropc to 0, when the non-default constructor and at
least the x86 initCPU utility function set it to 1. This makes more
sense since either the micropc doesn't matter as a concept if the
instruction isn't microcoded, or, unless redirected by a micropc
branch, you're going to want to execute the next microop and not just
repeat the first one.
Change-Id: I418ea986a071453563c4c8aad4fc4eb4f7beb641
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24184
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This mechanism is shared between ARM and x86, even if x86 has a typical
address range it choses to use. By moving this to the base class, it's
now possible for anybody to find out where the m5 ops are, and no ISA
specific assumptions need to be made.
Because the x86 address is well known, it's set in the x86 System
subclass as the default.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: Ifdb9f5cd1ce38b3c4dafa7566c50f245f14cf790
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23180
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Right now, there are only two places which call the pseudoInst function
directly, the ARM KVM CPU and the generic mmapped IPR. These two
callers currently use the generic "PseudoInstABI" which is just a
wrapper around the existing getArgument function.
In the future, this getArgument function will be disolved, and the
PseudoInstABI will be defined for each ABI. Since it currently mimics
the Linux ABI since gem5 can only handle one ABI at a time right now,
this implementation will probably be shared by linux system calls,
except that the pseudo inst implementation will eat return values since
those are returned through other means when the pseudo inst is based on
magic address ranges.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: Ied97e4a968795158873e492289a1058c8e4e411b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23178
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changes fixes two compilation errors when compiling with
FastModels. One is that CurrentMsn should be Iris::CurrentMsn and the
other is that currEL() function needs arch/arm/utility.hh header file.
Test by compiling GEM5 with FastModels:
scons -j64 build/ARM/gem5.opt \
USE_ARM_FASTMODEL=1 \
PVLIB_HOME=... \
MAXCORE_HOME=... \
ARMLMD_LICENSE_FILE=... \
Change-Id: Iabe0a5f25246591f99b57219428b8f87ecd3363c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23924
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This specialization will correspond specifically with the CortexA76,
instead of specializing the ThreadContext for ARM in general. Some
aspects of this class may need to move into the base IRIS thread
context class, but I'll leave that for a later change.
Change-Id: I9cbe527d36e6fda78601dc39c1963370cfa28b16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23787
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Fast models are in practice only ARM, so it's not that helpful to have
the ARM-ness factored out. It is, however, helpful to have aspects
which control how gem5 concepts like registers are mapped to fast model
concepts like resources, especially since these mappings may vary from
fast model to fast model.
For instance, it looks like the CortexA76 does not have predicate
vector registers. Rather than make all fast models support or not
support those registers, that can be done on a model by model basis.
Change-Id: I195da4a2f4d2f8593032d0d63e9fd3d20a240d01
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23786
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This was hardcoded as 5, but should be determined based on the memory
space IDs the fast model returns. What we do now is have a specific
override for ARM (perhaps conceptually the A76) which looks for an
address space called "Current" which seems to work well.
It's possible that the appropriate address space for a different model
might have a different number, or even a different name. This may need
to be further specialized/parameterized in those cases.
Change-Id: Ie1ef99675fd9bccab50b7fc7add16b82a93bd60b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22143
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These use the IRIS breakpoint API to stop the models at the appropriate
points. There seems to be a slightly wonky interaction between
breakpoints and stepping, where if you stop at a breakpoint and then
step, you might end up moving forward more than the number of requested
instructions.
Change-Id: I31f13a120cfc1ad2ec3669ee8befd6d21b328bb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22122
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The granularity bit should be set since the segment limit should be
interpreted as a number of pages, not bytes.
A comment indicates that NX support is enabled, but the bit wasn't
being set. That's now set to be consistent with FS mode.
The SVME bit is now turned off, since Intel CPUs don't have SVME, and
enabling it apparently makes them upset.
Also disable CR4 bits which enable features neither gem5 nor apparently
my workstation support.
Change-Id: I72d5a07871dede8763b0dd188a52fe5eb6bde6ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23361
Reviewed-by: Ayaz Akram <yazakram@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 will be used by the TLB to do the actual translation.
Unfortunately there isn't a great way to tell what translation type to
use, so we just go through all of them for now. The ARM subclass might
specialize and figure out which address spaces to use based on control
register state.
Change-Id: Id1fcad66554acf9d69af683917b3c2834f825da0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22118
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.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>
In Alpha and MIPS, the argc and argv values should be in what happens
to be the first and second syscall argument registers, but that's not
by definition. The process objects of both those ISAs know what
registers to use intrinsically, so there's also no reason to call out
to a helper method which acts as a part of the Process's interface to
the rest of gem5.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: Id8fa38ab1fc2ac6436e94ad41303439973fded10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23173
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
