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

Mark Rutland
2022-01-07T16:27:49Z

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
>