+ ArmISA.py: Enabling the feature adding QARMA algorithm as default.
+ faults.cc/faults.hh: Add PACTrapFault
+ includes/insts.isa: Adding new isa files.
+ aarch64.isa: Add decode part for PAC instructions
+ pauth.isa: Isa for PAC instructions
+ misc64.isa: PAC instructions templates
+ miscregs.cc/hh/types: New Registers for PAC Key low/high.
+ types.hh: Modification of system registers that were incomplete
for ARMv8
+ utility.hh: Add isSecureEL2 enabled. The function is there but will
always return false for now.
+ pauth_helpers.hh/cc: Implementation of auxiliar functions and derivates.
+ qarma.hh/cc: This functions follow ARMv8 reference pseudo code
implementing QARMA block cipher algorithms.
Change-Id: I3095a1279204206d9a816a4fb7fc176c18f9680b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25024
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because the fast models (or at least the one we've looked at) give
access to the integer registers mostly based on the current view of
those registers, it does its own flattening and prevents accessing most
of the raw storage locations without this extra level of mapping. To
store to the flattened locations, we need to unflatten the indexes and
in one case shift the mode so that we get the right values.
Some registers which have irrelevant values for fast model (the "PC"
which is actually diverted elsewhere, the zero register, microcode
registers, and the "dummy" register), and those are left out of the
mapping so that they return 0 and blow up gem5 when someone attempts to
set them.
Change-Id: Ia2d315d5ca4c8a65b17ad52beff3a366ca8b3d46
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23791
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These don't have anything in them at the moment since making some ISA
methods virtual and not inlined will likely add overhead, specifically
the ones for flattening registers. Some code may need to be rearranged
to minimize that overhead before the ISA objects can be truly put
behind a generic interface.
Change-Id: Ie36a771e977535a7996fdff701ce202bb95c8c58
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25007
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
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>
