Given that CPACR_EL1 is aliased to CPTR_EL2 when running at EL2 with VHE
enabled, we can just fall back to SetupExceptionLevel1() instead of
fiddling with the init values for CPTR_EL2.
While at it, use the existing define to refer to the E2H bit in HCR_EL2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Avoid a call and use a jump instead, so that the LR value does not
need to be recorded in a different register. This is generally neater,
but it also avoids potential confusion in the debugger, given that no
frame record is created for this call.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Even though the UEFI spec mentions that the EL1PCTEN and EL1PCEN bits in
CNTHCTL_EL2 must be set, this is not a requirement that applies to the
UEFI implementation, but a requirement that applies to the firmware
running at EL2 in cases where UEFI executes at EL1. (Note that the same
paragraphs mentions that CNTFRQ must be programmed with the timer
frequency, and this is only permitted at EL3).
Setting these bits has no effect when executing at EL2, and it is the
OS's job to reason about how to configure lower exception levels.
So drop the initialization of CNTHCTL_EL2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The architecture now permits HCR_EL2.E2H to be RES1, and so even though
the UEFI spec is silent on the matter, entering at EL2 with VHE enabled
is a condition that needs to be dealt with. In particular, virtual
machines running under nested virtualization on Apple M2 or newer will
enter in this manner
In this case, the CPTR_EL2 system register needs to be treated as if its
layout is identical to CPACR_EL1. Not doing so may result in all kinds
of surprises, but the most noticeable is an early crash on the use of
FP/SIMD registers, which get disabled inadvertently by this code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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>
CP_FULL_ACCESS is a misnomer, we only enable access to SIMD/FP state,
and although the register's mnemonic is CPACR_EL1, its full name is
"Architectural Feature Access Control Register", with AArch64 having no
coprocessors like AArch32 did, so the "CP" is also not appropriate.
Rename it to show it's the default value we use on entry, and define it
in terms of the existing CPACR_FPEN_FULL rather than a magic constant
with the same value to more clearly document that fact. Also update
comments to reflect all this (including the CPTR_EL2 case).
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
The existing code here predates its existence as it's assuming that
CPTR_EL2 has the traditional layout rather than being like CPACR_EL1
(likely also true elsewhere for other registers), and the UEFI spec has
nothing to say on the matter. One assumes the intent is that if you're
in EL2 you're in EL2 proper, and it would be very strange to enter EDK2
with E2H set. Document this existing assumption.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
AsmMacroIoLib.h and AsmMacroIoLibV8.h are used by the
CompilerIntrinsicsLib, which is moving to MdePkg. These
functions provide standard definitions for ARM/AARCH64
assembly code, respectively, and so are moved to the arch
directories in MdePkg to avoid MdePkg having a
dependency on ArmPkg.
Now that the files are in Arm/ and AArch64/ directories,
the filenames are changed to AsmMacroLib.h as we can
distinguish the architecture from the path.
AsmMacroIoLib.inc is unused and so is removed.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
PrePeiUniCore was already named rather awkwardly, but now that the
UniCore bit has become redundant too, let's rename it in a way that
conveys its purpose a bit better: Sec. This also matches what other
architectures and platforms tend to provide.
A straight rename would break all out-of-tree users, so clone it into a
new module with a fresh GUID, giving users some time to update.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The Sec library was built by the AARCH64 FVP models, but the binary was
unused because it was part of a legacy booting strategy from before ARM
Trusted Firmware came along.
This change requires changes in OpenPlatformPkg to remove the Sec binary
from the FVP build.
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
AARCH64 does not have a BIC-with-immediate instruction. GAS assembles it as a
AND with the immediate inverted, but Clang's integrated assembler emits an
error.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brendan Jackman <brendan.jackman@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15509 6f19259b-4bc3-4df7-8a09-765794883524
