memory.rst

  1==============================
  2Memory Layout on AArch64 Linux
  3==============================
  4
  5Author: Catalin Marinas <catalin.marinas@arm.com>
  6
  7This document describes the virtual memory layout used by the AArch64
  8Linux kernel. The architecture allows up to 4 levels of translation
  9tables with a 4KB page size and up to 3 levels with a 64KB page size.
 10
 11AArch64 Linux uses either 3 levels or 4 levels of translation tables
 12with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
 13(256TB) virtual addresses, respectively, for both user and kernel. With
 1464KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
 15virtual address, are used but the memory layout is the same.
 16
 17ARMv8.2 adds optional support for Large Virtual Address space. This is
 18only available when running with a 64KB page size and expands the
 19number of descriptors in the first level of translation.
 20
 21TTBRx selection is given by bit 55 of the virtual address. The
 22swapper_pg_dir contains only kernel (global) mappings while the user pgd
 23contains only user (non-global) mappings.  The swapper_pg_dir address is
 24written to TTBR1 and never written to TTBR0.
 25
 26When using KVM without the Virtualization Host Extensions, the
 27hypervisor maps kernel pages in EL2 at a fixed (and potentially
 28random) offset from the linear mapping. See the kern_hyp_va macro and
 29kvm_update_va_mask function for more details. MMIO devices such as
 30GICv2 gets mapped next to the HYP idmap page, as do vectors when
 31ARM64_SPECTRE_V3A is enabled for particular CPUs.
 32
 33When using KVM with the Virtualization Host Extensions, no additional
 34mappings are created, since the host kernel runs directly in EL2.
 35
 3652-bit VA support in the kernel
 37-------------------------------
 38If the ARMv8.2-LVA optional feature is present, and we are running
 39with a 64KB page size; then it is possible to use 52-bits of address
 40space for both userspace and kernel addresses. However, any kernel
 41binary that supports 52-bit must also be able to fall back to 48-bit
 42at early boot time if the hardware feature is not present.
 43
 44This fallback mechanism necessitates the kernel .text to be in the
 45higher addresses such that they are invariant to 48/52-bit VAs. Due
 46to the kasan shadow being a fraction of the entire kernel VA space,
 47the end of the kasan shadow must also be in the higher half of the
 48kernel VA space for both 48/52-bit. (Switching from 48-bit to 52-bit,
 49the end of the kasan shadow is invariant and dependent on ~0UL,
 50whilst the start address will "grow" towards the lower addresses).
 51
 52In order to optimise phys_to_virt and virt_to_phys, the PAGE_OFFSET
 53is kept constant at 0xFFF0000000000000 (corresponding to 52-bit),
 54this obviates the need for an extra variable read. The physvirt
 55offset and vmemmap offsets are computed at early boot to enable
 56this logic.
 57
 58As a single binary will need to support both 48-bit and 52-bit VA
 59spaces, the VMEMMAP must be sized large enough for 52-bit VAs and
 60also must be sized large enough to accommodate a fixed PAGE_OFFSET.
 61
 62Most code in the kernel should not need to consider the VA_BITS, for
 63code that does need to know the VA size the variables are
 64defined as follows:
 65
 66VA_BITS		constant	the *maximum* VA space size
 67
 68VA_BITS_MIN	constant	the *minimum* VA space size
 69
 70vabits_actual	variable	the *actual* VA space size
 71
 72
 73Maximum and minimum sizes can be useful to ensure that buffers are
 74sized large enough or that addresses are positioned close enough for
 75the "worst" case.
 76
 7752-bit userspace VAs
 78--------------------
 79To maintain compatibility with software that relies on the ARMv8.0
 80VA space maximum size of 48-bits, the kernel will, by default,
 81return virtual addresses to userspace from a 48-bit range.
 82
 83Software can "opt-in" to receiving VAs from a 52-bit space by
 84specifying an mmap hint parameter that is larger than 48-bit.
 85
 86For example:
 87
 88.. code-block:: c
 89
 90   maybe_high_address = mmap(~0UL, size, prot, flags,...);
 91
 92It is also possible to build a debug kernel that returns addresses
 93from a 52-bit space by enabling the following kernel config options:
 94
 95.. code-block:: sh
 96
 97   CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
 98
 99Note that this option is only intended for debugging applications
100and should not be used in production.