These VHE flags are not needed anymore.
They were used to trap EL2 access to VHE only registers (like CPACR_EL12)
when VHE was disabled (hcr.e2h = 0)
With the new faulting logic, we can just introduce VHE specific
callbacks checking for the hcr.e2h bitfield and returning an undefined
instruction if VHE is disabled.
In this way we don't have to add VHE only bits to every system register
Change-Id: I07bf9a9adc7a089bd45e718fb06d88488a2b7ed5
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61678
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is adding per-EL read/write callbacks to the MiscRegLUTEntry
class. The goal is to merge access permission and trapping logic into
these unified callbacks
As of now the default callbacks are simply reimplementing the access
permission code, checking for MiscRegLUTEntry flags. This is the default
behaviour for all registers.
Trapping code (from MiscRegOp64::trap) will be moved with a later patch
Change-Id: Ib4bb1b5d95319548de5e77e00258fd65c11d88d7
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61675
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: 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>
This patch is revamping/simplifying the access permission logic in the
ArmMMU (ArmMMU::s1PermBits64) by matching more closely the Arm
architecture reference manual pseudocode.
It also fixes VHE access permission: previous version was not
considering the EL2&0 translation regime.
Now EL2&0 is handled correctly through the new hasUnprivRegime method
Change-Id: I2689738f36a35c35cc4f2ef8af68ee2a3eef65e8
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/+/60969
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ARM no longer uses it's primitive FloatRegClass register file, but the
code in tarmac_record.cc still seems to access it? Should this code be
deleted, or rewritten to use the vector register file?
This code was used in the 32 bit ARM KVM code as well.
Change-Id: I6ed2ed9ae853fa4313294fdde4ce08d134fc12da
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49767
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The nightly tests, https://jenkins.gem5.org/job/nightly/219/, were
failing with the following error when running build/NULL/unittests.opt:
```
[ENUMDECL] m5.objects.ArmSystem, ArmExtension -> NULL/enums/ArmExtension.hh
terminate called after throwing an instance of 'pybind11::error_already_set'
what(): ModuleNotFoundError: No module named 'm5.objects.ArmSystem'
At:
<frozen importlib._bootstrap>(973): _find_and_load_unlocked
<frozen importlib._bootstrap>(991): _find_and_load
<frozen importlib._bootstrap>(1014): _gcd_import
/usr/lib/python3.8/importlib/__init__.py(127): import_module
build_tools/enum_hh.py(58): <module>
Aborted (core dumped)
scons: *** [build/NULL/enums/ArmExtension.hh] Error 134
```
The reason for this is the 'aapcs64.test' now transitively includes the
'ArmExtension' enum via this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/59471.
As this test now only works with the ARM ISA, a guard has been included.
As noted in the comment, GTest does not have the 'tags' parameter so the
'TARGET_ISA' environment variable was used. This will need updated when
the multi-isa code is incorporated.
Change-Id: I2793094bf7c813afd97933750332fa3f3b7bd8dd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59569
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
ArmFastModelComponents must *minimally* be guarded by "arm fastmodel"
tags, but may actually be covered by a more specific tag which is a
subset of "arm fastmodel", for instance if they are controlled by a
kconfig variable and may or may not be included in "gem5 lib"
independently of other sources which are part of "arm fastmodel".
The contents set up by ArmFastModelComponent are already guarded by a
fixed tag, so this change just needs to plumb through the tag as
specified when the ArmFastModelComponent is created instead.
Change-Id: I619c31107acda378a5439718e32938843f024e74
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59473
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Profiling gem5 has indicated computeAddrTop as one of the main
contributors in AArch64 simulation time
The utility function gets used in the critical path of gem5, which is
the memory translation subsystem. The function is supposed to compute a
rather trivial task: identifying the "real" most significant bit of a
virtual address.
This turns out to be quite expensive. Why?
The main issue is the AArch32/AArch64 check, which uses the ELIs32
helper. This performs a sequential read of several MiscReg
values until it confirms that an EL is indeed using AArch32 (or
AArch64).
This is functionally accurate but it is too expensive for the critical
path of a program.
This patch is addressing the issue by adding a Memoizer object for the
computeAddrTop function to the CachedState data structure, which is
already holding cached system register values for performance reasons.
Whenever we need to invalidate those sys reg values because of a change
in the translation system, we also flush/invalidate the memoizer cache
Change-Id: If42e945c650c293ace304fb4c35e709783bb82d4
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59151
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is splitting the purifyTaggedAddr helper in two
by introducing the maskTaggedAddress utility
* The first part computes the top bit of the address (computeAddrTop)
(This is required as the MSBs of a VA could be used to store
tags like in FEAT_Pauth)
* The second part applies some masking to the supplied
address (maskTaggedAddress) depending on the top bit to
purify the VA from the TAG
The motivation of this split will be clear in the next patch:
we want to memoize the expensive computeAddrTop. Memoizing
purifyTaggedAddr is inefficient as the first argument
is the VA of the memory request so multiple memory requests
will allocate multiple entries in the results cache and
memoization will rarely be used.
We will memoize the VA agnostic computeAddrTop instead
Change-Id: Ib3d8bb521be67a1f21c0891e753396299adf500b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59150
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
