You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike CPACR_EL1 whose reserved bits are solely RES0, CPTR_EL2 has some
RES1 bits, and so we should not clear them unless we know what they
mean. For example, when SVE was introduced, CPACR_EL1.ZEN occupied a
RES0 field and thus 0 means trap (which is what we get at EL1), but
CPTR_EL2.TZ occupied a RES1 field and thus 1 means trap, but we set it
to 0, so the environment is inconsistent between EDK2 and EL1 and EL2.
Another concrete case is for Morello, where the CEN/TC fields similarly
gate access to capability register state, but also alter exception
delivery and return, such that VBAR_ELx and ELR_ELx become capabilities.
So long as software adheres to RES0/1 this is backwards-compatible, but
since EDK2 does not do so here it inadvertently enables capability-based
exception delivery and return and thus, when run at EL2, gets stuck in a
trap loop when taking its first interrupt, but works just fine at EL1.
Fix this by setting all the RES1 fields in CPTR_EL2, following the
pattern for CPACR_EL1's non-zero initial value (due to setting FPEN so
as to not trap on SIMD/FP use), tested by running ArmVirtQemu-AARCH64
(DEBUG) on Morello QEMU with EL2 enabled.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
0 commit comments