This patch is adding a functional implementation of FEAT_XS. Unless we
operate with DVM enabled, TLBIs broadcasting is accomplished in 0 time;
so there is no timing benefit introduced by enabling FEAT_XS other than
the way it affects TLB management (invalidation)
Change-Id: I067cb8b7702c59c40c9bbb8da536a0b7f3337b5d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
According to the Arm architecture reference manual, it is possible to
force the broadcast of the following TLBIs:
AArch64: TLBI VMALLE1, TLBI VAE1, TLBI ASIDE1, TLBI VAAE1, TLBI VALE1,
TLBI VAALE1, IC IALLU, TLBI RVAE1, TLBI RVAAE1, TLBI RVALE1, and TLBI
RVAALE1.
AArch32: BPIALL, TLBIALL, TLBIMVA, TLBIASID, DTLBIALL, DTLBIMVA,
DTLBIASID, ITLBIALL, ITLBIMVA, ITLBIASID, TLBIMVAA, ICIALLU, TLBIMVAL,
and TLBIMVAAL.
Via the HCR_EL2.FB bit
Change-Id: Ib11aa05cd202fadfbd9221db7a2043051196ecbd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This is making it easier for TLBI instructions to share code. Common
code (under the form of tlbi* functions) are closely matching the
instruction description in the Arm pseudocode
Change-Id: If10c22fb4a7df2bcd0335e9761286ad3c458722b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Those were not part of the performTlbi switch and simulation was
therefore panicking when they were encountered
Change-Id: Ifbe0b89e45539df4abc147ac5970b0caf0d9dfdc
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This is the final step in the transformation process.
We limit the use of the "managing Exception Level" for
a translation in favour of the more standard "Translation
Regime"
This greatly simplifies our code, especially with VHE
where the managing el (EL2) could handle to different
translation regimes (EL and EL2&0).
We can therefore remove the isHost flag wherever it got
used. That case is automatically handled by the proper
regime value (EL2&0)
Change-Id: Iafd1d2ce4757cfa6598656759694e5e7b05267ad
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The Xt is not part of the architectural name of the register
and it was likely added with the introduction of extended
register (Xt) TLBIs in Armv8 to differentiate them with
the old Armv7 ones.
The use of _Xt was not consistent anyway: newer TLBIs were
already omitting it.
Change-Id: Ic805340ffa7b5770e3b75a71bfb76e055e651f8b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This patch is amending encodeAArch64SysReg so that it covers the case
where there are no arch numbers available for the misc index passed as
an argument.
This could happen if the register ID is a gem5 pseudo register which is
not associated with any architected op1/op2/crn/crm tuple.
Rather than panicking we return a nullopt.
Change-Id: I7ab70467105ef93c0c78ac4e999c7dc8e5e09925
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Prior to gem5 v21.2, partial translation entries were not cached within
the TLB, therefore Last Level (only) TLBI instructions were invalidating
every entry.
Now that we store translations from several lookup levels we are
currently over-invalidating partial translations. This patch is
adding a boolean flag to TLBIMVAA and TLBIMVA, allowing to discard
a match if the TLBI is targeting complete translations only
and the entry holds a partial translation
Change-Id: I86fa39c962355d9c566ee8aa29bebcd9967c8c57
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62453
Tested-by: kokoro <noreply+kokoro@google.com>
Fixing invalidation behaviour for the following stage 2 TLB maintainance
instructions
MISCREG_TLBI_IPAS2E1_Xt
MISCREG_TLBI_IPAS2LE1_X
MISCREG_TLBI_IPAS2E1_Xt
MISCREG_TLBI_IPAS2LE1_Xt
1) Do nothing if EL2 is not enabled in the current security state
2) If we are in secure state, the 63 bit of the Xt register selects
the security domain (s/ns) of the invalidated entries
Change-Id: I4573ed60ce619bcefd9cb05f00c5d3fcfa8d3199
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61751
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The iss field is only used when the MSR/MRS instruction
gets trapped. Rather than generating it at decode time,
we generate the value within the trap method instead
This avoids the confusion of having a MSR/MRS register
instruction storing an immediate field
Later patches will change this even further by generating the
iss field on the fly ONLY if the instruction gets trapped
Change-Id: I97fdcf54d9643ea79a1f9d052073320ee68109fd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61670
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This register is used since the Linux kernel 5.6 aarch64 boot.
This register indicates CPU capabilities in aarch32 mode, and it has the
same value as the aarch32 ID_ISAR6 miscregister, which is also added.
The capability values of those registers are analogous to those present in
aarch64 accessible ID_AA64ISAR0_EL1 and ID_AA64ISAR1_EL1, which refer to
aarch64 capabilities however, and were already implemented before this
commit.
The arm architecture document clarifies that reads to this system register
location before it had been defined should return 0, but we were faulting
instead:
> Prior to the introduction of the features described by this register,
this register was unnamed and reserved, RES0 from EL1, EL2, and EL3.
Change-Id: I70e99536dc98925e88233fd4c6887bbcdd5d87dc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30935
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This has been in this file since it was created in 2009. No global "using
namespace ${NAMESPACE}" should ever appear in a .hh file since then that
namespace is "used" in all files that include the .hh, even if they
aren't aware of it or even actively don't want to.
Change-Id: Idb7d7c5b959077eb4905fbb2044aa55959b8f37f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34155
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The components in base/loader were moved into a namespace called
Loader. This will make it easier to add loader components with fairly
short natural names which don't invite name collisions.
gem5 should use namespaces more in general for that reason and to make
it easier to write independent components without having to worry about
name collisions being added in the future.
Unfortunately this namespace has the same name as a class used to load
an object file into a process object. These names can be disambiguated
because the Process loader is inside the Process scope and the Loader
namespace is at global scope, but it's still confusing to read.
Fortunately, this shouldn't last for very long since the responsibility
for loading Processes is going to move to a fake OS object which will
expect to load a particular type of Process, for instance, fake 64 bit
x86 linux will load either 32 or 64 bit x86 processes.
That means that the capability to feed any binary that matches the
current build into gem5 and have gem5 figure out what to do with it
will likely be going away in the future. That's likely for the best,
since it will force users to be more explicit about what they're trying
to do, ie what OS they want to try to load a given binary, and also
will prevent loading two or more Processes which are for different OSes
to the same system, something that's possible today as far as I know
since there are no consistency checks.
Change-Id: Iea0012e98f39f5e20a7c351b78cdff9401f5e326
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24783
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
+ 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>
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>
MSR <pstatefield>, #imm is used for setting a PSTATE field using an
immediate. Current implementation has the following flaws:
* There is no base MSR immediate definition: all the existing
PSTATE fields have a different class definition
* Those implementation make use of a generic data64 base class
which results in a wrong disassembly (pstate register is printed as an
integer register).
This patch is fixing this by defining a new base class (MiscRegImmOp64)
and new related templates. In this way, we aim to ease addition of new
PSTATE fields (in ARMv8.x)
Change-Id: I71b630ff32abe1b105bbb3ab5781c6589b67d419
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/+/19728
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When dumping the opcode that caused an Undefined Instruction, we just
want to dump the real instruction encoding, and not the extended version
with metabits (like thumb, bigThumb etc). This was not appening when
panicking in SE mode.
The patch is also replacing custom masking in the Unknown(64) disassembler
in favour of ArmStaticInstruction::encoding() helper.
Change-Id: I9eb6fd145d02b4b07bb51f0bd89ca014d6d5a6de
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/+/18395
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
While there is a AArch32 class for instructions accessing implementation
defined registers, we are lacking for the AArch64 counterpart.
we were relying on FailUnimplemented, which is untrappable at EL2 (except
for HCR_EL2.TGE) since it is just raising Undefined Instruction.
Change-Id: I923cb914658ca958af031612cf005159707b0b4f
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/13779
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This patch refactors AArch64 MSR/MRS trapping, by moving the trapping
helpers in arch/arm/utility and in the isa code into a MiscRegOp64
class.
This class is the Base class for a generic AArch64 instruction which is
making use of system registers (MiscReg), like MSR,MRS,SYS. The common
denominator or those instruction is the chance that the system register
access is trapped to an upper Exception level. MiscRegOp64 is providing
that feature.
What do we gain? Other "pseudo" instructions, like access to
implementation defined registers can inherit from this class to make use
of the trapping functionalities even if there is no data movement
between GPRs and system register.
Change-Id: I0924354db100de04f1079a1ab43d4fd32039e08d
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/13778
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This patch fixes the disassembly of AArch64 Exception Generating
instructions, which were not printing the encoded immediate field. This
has been accomplished by changing their underlying type to a newly
defined one.
Change-Id: If58ae3e620d2baa260e12ecdc850225adfcf1ee5
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/8368
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
