On Fri, Jan 07, 2022 at 04:00:55PM +0000, Andre Przywara wrote: > The ARMv8.4 architecture revision introduced the EL2 exception level > to the secure world. Clarify the existing wording to make sure that > Linux relies on being executed in the non-secure state. > > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx> > --- > Documentation/arm64/booting.rst | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > index 52d060caf8bb..07cb34ed4200 100644 > --- a/Documentation/arm64/booting.rst > +++ b/Documentation/arm64/booting.rst > @@ -10,9 +10,9 @@ This document is based on the ARM booting document by Russell King and > is relevant to all public releases of the AArch64 Linux kernel. > > The AArch64 exception model is made up of a number of exception levels > -(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure > -counterpart. EL2 is the hypervisor level and exists only in non-secure > -mode. EL3 is the highest priority level and exists only in secure mode. > +(EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure > +counterpart. EL2 is the hypervisor level, EL3 is the highest priority > +level and exists only in secure mode. Both are architecturally optional. > > For the purposes of this document, we will use the term `boot loader` > simply to define all software that executes on the CPU(s) before control > @@ -167,8 +167,8 @@ Before jumping into the kernel, the following conditions must be met: > > All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, > IRQ and FIQ). > - The CPU must be in either EL2 (RECOMMENDED in order to have access to > - the virtualisation extensions) or non-secure EL1. > + The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order > + to have access to the virtualisation extensions), or in EL1. ^^ Nit: double space It might be clearer to explicitly say "non-secure EL2" and "non-secure EL1" here, but either way this looks good to me, so with the whitespace fixed: Reviewed-by: Mark Rutland <mark.rutland@xxxxxxx> Thanks, Mark.