This is needed when a CMO triggers an exception (e.g. DataAbort) In that
case the faulting address should be the one encoded in the instruction
rather than the cacheline address:
According to armarm:
If a memory fault that sets FAR_EL1 is generated from a data cache
maintenance or other DC instruction, FAR_EL1[63:0] holds the address
specified in the register argument of the instruction.
Change-Id: I6d0dadbef6e70db57438b01a76c5def3bdd2d974
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22443
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ARMv8.1-PAN adds a new bit to PSTATE. When the value of this PAN state
bit is 1, any privileged data access from EL1 or EL2 to a virtual memory
address that is accessible at EL0 generates a Permission fault.
This feature is mandatory in ARMv8.1 implementations.
This feature is supported in AArch64 and AArch32 states.
The ID_AA64MMFR1_EL1.PAN, ID_MMFR3_EL1.PAN, and ID_MMFR3.PAN fields
identify the support for ARMv8.1-PAN.
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I94a76311711739dd2394c72944d88ba9321fd159
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19729
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ARMv8 differs from ARMv7 with the presence of RVBAR register, which
contains the implementation defined reset address when EL3 is not
implemented.
The entry 0x0 in the AArch32 vector table, once used for the Reset
Vector, is now marked as "Not used", stating that it is now IMPLEMENTATION
DEFINED. An implementation might still use this vector table entry to
hold the Reset vector, but having a Reset address != than the general
vector table (for any other exception) is allowed.
At the moment any Reset exception is still using 0 as a vector table
base address. This patch is extending the ArmSystem::resetAddr64 to
ArmSystem::resetAddr so that it can be used for initializing
MVBAR/RVBAR. In order to do so, we are providing a specialized behavior
for the Reset exception when evaluating the vector base address.
Change-Id: I051a730dc089e194db3b107bbed19251c661f87e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/14000
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The fault status code generated by a Prefetch/Data Fault was containing
a wrong value when the fault was triggered in aarch32 but handled in
aarch64. This because the encoding differs between the two ISAs and the
encoder was just checking the starting ISA rather than the the ending
one. In this case the getFsr must be called after we know which is the
ending ISA, which happens only after ArmFault::invoke gets called. The
fsc update hence happens before writing into the Syndrome register.
Change-Id: I725f12b6dcc0178f608233bd3d15e466d1cd1ffc
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/8362
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
There is a set of internal variables in ArmFault thats get updated once
the fault is invoked (ArmFault::invoke). Sometimes we rely on those even
if the fault is generated but not invoked (e.g. when checking if a
memory access is producing a fault). This patch is moving the update
functionalities inside a public method so that a client can make use of
it even when not invoking the fault.
Change-Id: I3ac5b6835023f28ec569fe25487dffa356e1b2fd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/8361
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The stats are silently non-copy constructible. Therefore, when someone
copy-constructs any object with stats, asserts happen when registering
the stats, as they were not constructed in the intended way.
This patch solves that by explicitly deleting the copy constructor,
trading an obscure run-time assert for a compile-time somehow more
meaningful error meassage.
This triggers some compilation errors as the FaultStats in the fault
definitions of ARM and SPARC use brace-enclosed initialisations in which
one of the elements derives from DataWrap, which is not
copy-constructible anymore. To fix that, this patch also adds a
constructor for the FaultVals in both ISAs.
Change-Id: I340e203b9386609b32c66e3b8918a015afe415a4
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/8082
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The old code chose vector offset associated with exceptions taken
to EL3 by incorrectly using "from64", which is associated with the
exception level where the exception was taken from. However, the
offset should depends on the ISA of the lower EL and not of the
starting EL itself, as specified in ARM ARM. This patch corrects
this by implementing the method in AArch64.TakeException in ARM ARM.
Change-Id: I8f7c9aa777c5f2eef9e2d89c36e9daee23f3a822
Reviewed-by: Jack Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/8001
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Supervisor Trap is supposed to be able to handle exceptions routed
to EL2, which is enabled by HCR_EL2.TGE. This fix adds routeToHyp()
function to Supervisor Trap to handle this, similar to that in
UndefinedFault, DataAbort, etc.
Change-Id: I1fcf9f2d445ecbc13c8f6d3b7d599728b0250ab7
Reviewed-by: Jack Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/7961
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
These files aren't a collection of miscellaneous stuff, they're the
definition of the Logger interface, and a few utility macros for
calling into that interface (panic, warn, etc.).
Change-Id: I84267ac3f45896a83c0ef027f8f19c5e9a5667d1
Reviewed-on: https://gem5-review.googlesource.com/6226
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
This Patch is removing the FlushPipe ArmFault, which was used for
flushing the pipeline in favour of the general IsSquashAfter StaticInstr
flag. Using a fault was preventing tracers from tracing barriers like
ISB and from adding them to the instruction count
Change-Id: I176e9254eca904694f2f611eb486c55e50ec61ff
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5361
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Compiling gem5 with recent version of clang (4 and 5) triggers
warnings that are treated as errors:
* Global templatized static functions result in a warning if they
are not used. These should either be declared as static inline or
without the static identifier to avoid the warning.
* Some templatized classes contain static variables. The
instantiated versions of these variables / templates need to be
explicitly declared to avoid a compiler warning.
Change-Id: Ie8261144836e94ebab7ea04ccccb90927672c257
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3420
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
In arch/arm/faults.hh, template the static member vals require explicit
specialisation to avoid compiler warnings.
Change-Id: Ie404ccaa43269cb1bb819e33153e776abbf3a79b
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
This patch adds the AArch64 instruction hvc which raises an exception
from EL1 into EL2. The host OS uses this instruction to world switch
into the guest.
Change-Id: I930ee43f4f0abd4b35a68eb2a72e44e3ea6570be
Another churn to clean up undefined behaviour, mostly ARM, but some
parts also touching the generic part of the code base.
Most of the fixes are simply ensuring that proper intialisation. One
of the more subtle changes is the return type of the sign-extension,
which is changed to uint64_t. This is to avoid shifting negative
values (undefined behaviour) in the ISA code.
This patch optimises the passing of StaticInstPtr by avoiding copying
the reference-counting pointer. This avoids first incrementing and
then decrementing the reference-counting pointer.
Note: AArch64 and AArch32 interworking is not supported. If you use an AArch64
kernel you are restricted to AArch64 user-mode binaries. This will be addressed
in a later patch.
Note: Virtualization is only supported in AArch32 mode. This will also be fixed
in a later patch.
Contributors:
Giacomo Gabrielli (TrustZone, LPAE, system-level AArch64, AArch64 NEON, validation)
Thomas Grocutt (AArch32 Virtualization, AArch64 FP, validation)
Mbou Eyole (AArch64 NEON, validation)
Ali Saidi (AArch64 Linux support, code integration, validation)
Edmund Grimley-Evans (AArch64 FP)
William Wang (AArch64 Linux support)
Rene De Jong (AArch64 Linux support, performance opt.)
Matt Horsnell (AArch64 MP, validation)
Matt Evans (device models, code integration, validation)
Chris Adeniyi-Jones (AArch64 syscall-emulation)
Prakash Ramrakhyani (validation)
Dam Sunwoo (validation)
Chander Sudanthi (validation)
Stephan Diestelhorst (validation)
Andreas Hansson (code integration, performance opt.)
Eric Van Hensbergen (performance opt.)
Gabe Black
Only create a memory ordering violation when the value could have changed
between two subsequent loads, instead of just when loads go out-of-order
to the same address. While not very common in the case of Alpha, with
an architecture with a hardware table walker this can happen reasonably
frequently beacuse a translation will miss and start a table walk and
before the CPU re-schedules the faulting instruction another one will
pass it to the same address (or cache block depending on the dendency
checking).
This patch has been tested with a couple of self-checking hand crafted
programs to stress ordering between two cores.
The performance improvement on SPEC benchmarks can be substantial (2-10%).
SEV instructions were originally implemented to cause asynchronous squashes
via the generateTCSquash() function in the O3 pipeline when updating the
SEV_MAILBOX miscReg. This caused race conditions between CPUs in an MP system
that would lead to a pipeline either going inactive indefinitely or not being
able to commit squashed instructions. Fixed SEV instructions to behave like
interrupts and cause synchronous sqaushes inside the pipeline, eliminating
the race conditions. Also fixed up the semantics of the WFE instruction to
behave as documented in the ARMv7 ISA description to not sleep if SEV_MAILBOX=1
or unmasked interrupts are pending.
Ran all the source files through 'perl -pi' with this script:
s|\s*(};?\s*)?/\*\s*(end\s*)?namespace\s*(\S+)\s*\*/(\s*})?|} // namespace $3|;
s|\s*};?\s*//\s*(end\s*)?namespace\s*(\S+)\s*|} // namespace $2\n|;
s|\s*};?\s*//\s*(\S+)\s*namespace\s*|} // namespace $1\n|;
Also did a little manual editing on some of the arch/*/isa_traits.hh files
and src/SConscript.
Also move the "Fault" reference counted pointer type into a separate file,
sim/fault.hh. It would be better to name this less similarly to sim/faults.hh
to reduce confusion, but fault.hh matches the name of the type. We could change
Fault to FaultPtr to match other pointer types, and then changing the name of
the file would make more sense.
This fault can used to flush the pipe, not including the faulting instruction.
The particular case I needed this was for a self-modifying code. It needed to
drain the store queue and force the following instruction to refetch from
icache. DCCMVAC cp15 mcr instruction is modified to raise this fault.
Instead of panic immediately when these instructions are executed, an
UndefinedInstruction fault is returned. In FS mode (not currently
implemented), this is the fault that should, to my knowledge, be triggered in
these situations and should be handled using the normal architected
mechanisms. In SE mode, the fault causes a panic when it's invoked that gives
the same information as the instruction did. When/if support for speculative
execution of ARM is supported, this will allow a mispeculated and unrecognized
and/or unimplemented instruction from causing a panic. Only once the
instruction is going to be committed will the fault be invoked, triggering the
panic.
