From 75516c75a72b5629736c611cf45058d95978a9f2 Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Fri, 23 Apr 2021 18:51:34 +0100 Subject: arm64: doc: Add brk/mmap/mremap() to the Tagged Address ABI Exceptions Prior to commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"), the kernel allowed tagged addresses to be passed to the brk/mmap/mremap() syscalls. This relaxation was tightened in 5.6 (backported to stable 5.4) but the tagged-address-abi.rst document was only partially updated. Signed-off-by: Catalin Marinas Fixes: dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()") Reported-by: Peter Maydell Cc: Will Deacon Cc: Vincenzo Frascino Link: https://lore.kernel.org/r/20210423175134.14838-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas --- Documentation/arm64/tagged-address-abi.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst index cbc4d4500241..459e6b66ff68 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arm64/tagged-address-abi.rst @@ -113,6 +113,12 @@ ABI relaxation: - ``shmat()`` and ``shmdt()``. +- ``brk()`` (since kernel v5.6). + +- ``mmap()`` (since kernel v5.6). + +- ``mremap()``, the ``new_address`` argument (since kernel v5.6). + Any attempt to use non-zero tagged pointers may result in an error code being returned, a (fatal) signal being raised, or other modes of failure. -- cgit v1.2.3 From ee61f36d3e46bdb1c8910d1bd5c0863130c7b951 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Mon, 12 Apr 2021 16:19:53 +0100 Subject: arm64: Relax booting requirements for configuration of traps Currently we require that a number of system registers be configured to disable traps when starting the kernel. Add an explicit note that the requirement is that the system behave as if the traps are disabled so transparent handling of the traps is fine, this should be implicit for people familiar with working with standards documents but it doesn't hurt to be explicit. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210412151955.16078-2-broonie@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/booting.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 4fcc00add117..b21049ab6c69 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -279,7 +279,10 @@ Before jumping into the kernel, the following conditions must be met: The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must -enter the kernel in the same exception level. +enter the kernel in the same exception level. Where the values documented +disable traps it is permissible for these traps to be enabled so long as +those traps are handled transparently by higher exception levels as though +the values documented were set. The boot loader is expected to enter the kernel on each CPU in the following manner: -- cgit v1.2.3 From b30dbf4d936224f83a98bea2328ff09e644a25b2 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Mon, 12 Apr 2021 16:19:54 +0100 Subject: arm64: Explicitly require that FPSIMD instructions do not trap We do not explicitly require that systems with FPSIMD support and EL3 have disabled EL3 traps when the kernel is started, while it is unlikely that systems will get this wrong for the sake of completeness let's spell it out. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210412151955.16078-3-broonie@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/booting.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index b21049ab6c69..4d0e323c0a35 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -277,6 +277,16 @@ Before jumping into the kernel, the following conditions must be met: - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1. + For CPUs with Advanced SIMD and floating point support: + + - If EL3 is present: + + - CPTR_EL3.TFP (bit 10) must be initialised to 0b0. + + - If EL2 is present and the kernel is entered at EL1: + + - CPTR_EL2.TFP (bit 10) must be initialised to 0b0. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. Where the values documented -- cgit v1.2.3 From ff1c42cdfbcfba4cc75f3e21ed819ded2dad5f3e Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Mon, 12 Apr 2021 16:19:55 +0100 Subject: arm64: Explicitly document boot requirements for SVE We do not currently document the requirements for configuration of the SVE system registers when booting the kernel, let's do so for completeness. We don't have a hard requirement that the vector lengths configured on different CPUs on initial boot be consistent since we have logic to constrain to the minimum supported value but we will reject any late CPUs which can't support the current maximum and introducing the concept of late CPUs seemed more complex than was useful so we require that all CPUs use the same value. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210412151955.16078-4-broonie@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/booting.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 4d0e323c0a35..18b8cc1bf32c 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -287,6 +287,24 @@ Before jumping into the kernel, the following conditions must be met: - CPTR_EL2.TFP (bit 10) must be initialised to 0b0. + For CPUs with the Scalable Vector Extension (FEAT_SVE) present: + + - if EL3 is present: + + - CPTR_EL3.EZ (bit 8) must be initialised to 0b1. + + - ZCR_EL3.LEN must be initialised to the same value for all CPUs the + kernel is executed on. + + - If the kernel is entered at EL1 and EL2 is present: + + - CPTR_EL2.TZ (bit 8) must be initialised to 0b0. + + - CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11. + + - ZCR_EL2.LEN must be initialised to the same value for all CPUs the + kernel will execute on. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. Where the values documented -- cgit v1.2.3 From 5d8505fd039c1e757ad3490e46fe0fe73d78e2e0 Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Wed, 5 May 2021 14:28:45 +0100 Subject: arm64: Fix the documented event stream frequency It should be 10KHz, matching the ARCH_TIMER_EVT_STREAM_PERIOD_US of 100us. Note that this is only a documentation bug. Fixes: 611a7bc74ed2 ("arm64: docs: describe ELF hwcaps") Signed-off-by: Catalin Marinas Cc: Mark Rutland Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210505132845.23698-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas --- Documentation/arm64/elf_hwcaps.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index 87821662eeb2..ec1a5a63c1d0 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -74,7 +74,7 @@ HWCAP_ASIMD HWCAP_EVTSTRM The generic timer is configured to generate events at a frequency of - approximately 100KHz. + approximately 10KHz. HWCAP_AES Functionality implied by ID_AA64ISAR0_EL1.AES == 0b0001. -- cgit v1.2.3