Re: [PATCH 2/2] arm64: booting.rst: Cover Armv8-R64

[Mark Rutland <mark.rutland@arm.com>]

On Fri, Jan 07, 2022 at 04:00:56PM +0000, Andre Przywara wrote:
> There is a new revision of the ARMv8-R architecture [1], which
> optionally introduces kernel compatibility - by introducing an MMU
> into EL1 and EL0.
> Linux can run on such an implementation, if it is entered in EL1 and
> VMSA is both implemented and enabled for that exception level.
> 
> Clarify our kernel boot protocol to make this an officially supported
> mode of operation, but also limit the expectations about running in
> secure state (which is the only security state in v8-R).
> 
> Also we heavily rely on the Virtual Memory System Architecture (VMSA),
> make this explicit in the text, as this allows to cover v8-R64 as well.
> 
> [1] https://developer.arm.com/documentation/ddi0600/latest/
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  Documentation/arm64/booting.rst | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> index 07cb34ed4200..99fab4d7e7ad 100644
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -167,8 +167,13 @@ 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 non-secure state, either in EL2 (RECOMMENDED in order
> -  to have access  to the virtualisation extensions), or in EL1.
> +  If the CPU supports two security states, Linux must be entered in
> +  non-secure state, either in EL2 (RECOMMENDED in order to have access
> +  to the virtualisation extensions) or in EL1.
> +  If the CPU only supports a single security state, Linux can be run even
> +  when this single state is "secure".

Hmm... we've never supported running on the secure side so far, so are we
certain that everything actually works in such configs?

I know that some control fields (e.g. for filtering debug/tracing and so on)
differ across S/NS, and IIRC there's a bunch of GIC configuration that could
differ (but I could be mistaken).

Is there anything we need to have initialized differently by firmware?

Thanks,
Mark.

> +  The exception level the kernel is entered in must support the VMSA
> +  memory model.
>  
>  - Caches, MMUs
>  
> -- 
> 2.25.1
>