From 3e5be4e11aac40eb9d3ea6b5e79b7e95b0a6ebe5 Mon Sep 17 00:00:00 2001 From: Anshuman Khandual Date: Wed, 11 Dec 2024 12:24:24 +0530 Subject: [PATCH 1/3] docs: arm64: Document EL3 requirements for cpu debug architecture This documents EL3 requirements for debug architecture. The register field MDCR_EL3.TDA needs to be cleared for accesses into debug registers without any trap being generated into EL3. CPU debug registers like DBGBCR_EL1, DBGBVR_EL1, DBGWCR_EL1, DBGWVR_EL1 and MDSCR_EL1 are already being accessed for HW breakpoint, watchpoint and debug monitor implementations on the platform. Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: Jonathan Corbet Cc: linux-arm-kernel@lists.infradead.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual Link: https://lore.kernel.org/r/20241211065425.1106683-2-anshuman.khandual@arm.com Signed-off-by: Will Deacon --- Documentation/arch/arm64/booting.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst index 3278fb4bf219..1b3ac1394e5f 100644 --- a/Documentation/arch/arm64/booting.rst +++ b/Documentation/arch/arm64/booting.rst @@ -449,6 +449,12 @@ Before jumping into the kernel, the following conditions must be met: - HFGWTR_EL2.nGCS_EL0 (bit 52) must be initialised to 0b1. + - For CPUs with debug architecture i.e FEAT_Debugv8pN (all versions): + + - If EL3 is present: + + - MDCR_EL3.TDA (bit 9) must be initialized 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 From 1e4a5e3679cc4d037982bfc822d939d5ba954e70 Mon Sep 17 00:00:00 2001 From: Anshuman Khandual Date: Wed, 11 Dec 2024 12:24:25 +0530 Subject: [PATCH 2/3] docs: arm64: Document EL3 requirements for FEAT_PMUv3 This documents EL3 requirements for FEAT_PMUv3. The register field MDCR_EL3 .TPM needs to be cleared for accesses into PMU registers without any trap being generated into EL3. PMUv3 registers like PMCCFILTR_EL0, PMCCNTR_EL0 PMCNTENCLR_EL0, PMCNTENSET_EL0, PMCR_EL0, PMEVCNTR_EL0, PMEVTYPER_EL0 etc are already being accessed for perf HW PMU implementation. Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: Jonathan Corbet Cc: linux-arm-kernel@lists.infradead.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Anshuman Khandual Link: https://lore.kernel.org/r/20241211065425.1106683-3-anshuman.khandual@arm.com Signed-off-by: Will Deacon --- Documentation/arch/arm64/booting.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst index 1b3ac1394e5f..cad6fdc96b98 100644 --- a/Documentation/arch/arm64/booting.rst +++ b/Documentation/arch/arm64/booting.rst @@ -455,6 +455,12 @@ Before jumping into the kernel, the following conditions must be met: - MDCR_EL3.TDA (bit 9) must be initialized to 0b0 + - For CPUs with FEAT_PMUv3: + + - If EL3 is present: + + - MDCR_EL3.TPM (bit 6) must be initialized 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 From fd10f08cb57b891a9bc7cef4ffb26772d91bebf5 Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Mon, 13 Jan 2025 16:34:00 +0000 Subject: [PATCH 3/3] Documentation: arm64: Remove stale and redundant virtual memory diagrams The arm64 'memory.rst' file tries to document the virtual memory map and the translation procedure for a couple of kernel configurations. Unfortunately, the virtual memory map changes relatively frequently and we support considerably more configurations than we did when the docs were introduced (e.g. we now have support for 16KiB pages and 52-bit addressing). Furthermore, the Arm ARM is the definitive resource for the translation procedure and so there's little point in duplicating part of that information in the kernel documentation. Rather than continue trying (and failing) to maintain these diagrams, let's rip them out. The kernel page-table can be dumped using CONFIG_PTDUMP_DEBUGFS if necesssary. Link: https://lore.kernel.org/r/20250102065554.1533781-1-sangmoon.kim@samsung.com Reported-by: Sangmoon Kim Signed-off-by: Will Deacon --- Documentation/arch/arm64/memory.rst | 65 ----------------------------- 1 file changed, 65 deletions(-) diff --git a/Documentation/arch/arm64/memory.rst b/Documentation/arch/arm64/memory.rst index 8a658984b8bb..678fbb418c3a 100644 --- a/Documentation/arch/arm64/memory.rst +++ b/Documentation/arch/arm64/memory.rst @@ -23,71 +23,6 @@ swapper_pg_dir contains only kernel (global) mappings while the user pgd contains only user (non-global) mappings. The swapper_pg_dir address is written to TTBR1 and never written to TTBR0. - -AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: - - Start End Size Use - ----------------------------------------------------------------------- - 0000000000000000 0000ffffffffffff 256TB user - ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map - [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region] - ffff800000000000 ffff80007fffffff 2GB modules - ffff800080000000 fffffbffefffffff 124TB vmalloc - fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) - fffffbfffe000000 fffffbfffe7fffff 8MB [guard region] - fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space - fffffbffff800000 fffffbffffffffff 8MB [guard region] - fffffc0000000000 fffffdffffffffff 2TB vmemmap - fffffe0000000000 ffffffffffffffff 2TB [guard region] - - -AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support):: - - Start End Size Use - ----------------------------------------------------------------------- - 0000000000000000 000fffffffffffff 4PB user - fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map - [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region] - ffff800000000000 ffff80007fffffff 2GB modules - ffff800080000000 fffffbffefffffff 124TB vmalloc - fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) - fffffbfffe000000 fffffbfffe7fffff 8MB [guard region] - fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space - fffffbffff800000 fffffbffffffffff 8MB [guard region] - fffffc0000000000 ffffffdfffffffff ~4TB vmemmap - ffffffe000000000 ffffffffffffffff 128GB [guard region] - - -Translation table lookup with 4KB pages:: - - +--------+--------+--------+--------+--------+--------+--------+--------+ - |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| - +--------+--------+--------+--------+--------+--------+--------+--------+ - | | | | | | - | | | | | v - | | | | | [11:0] in-page offset - | | | | +-> [20:12] L3 index - | | | +-----------> [29:21] L2 index - | | +---------------------> [38:30] L1 index - | +-------------------------------> [47:39] L0 index - +----------------------------------------> [55] TTBR0/1 - - -Translation table lookup with 64KB pages:: - - +--------+--------+--------+--------+--------+--------+--------+--------+ - |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| - +--------+--------+--------+--------+--------+--------+--------+--------+ - | | | | | - | | | | v - | | | | [15:0] in-page offset - | | | +----------> [28:16] L3 index - | | +--------------------------> [41:29] L2 index - | +-------------------------------> [47:42] L1 index (48-bit) - | [51:42] L1 index (52-bit) - +----------------------------------------> [55] TTBR0/1 - - When using KVM without the Virtualization Host Extensions, the hypervisor maps kernel pages in EL2 at a fixed (and potentially random) offset from the linear mapping. See the kern_hyp_va macro and