## Overview For an introduction to `aarch64` instruction sets and nomenclature, please see the [CPU features section](https://ports.archlinux.page/aarch64/#cpu-features) under Device Support on the aarch64 Ports page. The analogue of this issue for the `x86_64` architecture is the [microarchitecture concept](https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels) for which an [RFC](https://rfc.archlinux.page/0002-x86-64-v3-microarchitecture/) exists. Many of the same considerations raised in that RFC are also relevant for `aarch64`. Additionally, it is also likely that the absence of certain CPU instructions (e.g. [CRC32](https://developer.arm.com/documentation/dui0801/l/A32-and-T32-Instructions/CRC32--A32-) and/or [Large System Extensions (LSE)](https://learn.arm.com/learning-paths/servers-and-cloud-computing/lse/intro/)) can cause issues building certain packages. This was first identified as an issue in [qt6-webengine](https://gitlab.archlinux.org/archlinux/packaging/packages/qt6-webengine) (and chromium), but the package no longer suffers from the issue as of 6.10.1-1. Because the number of packages affected is not fully known/documented, it is not clear how costly it is to try to support ARMv8 vs ARMv8.2. While other distributions do "support" v8, that fact alone doesn't clarify the cost they bear to do so. What is clear ex-ante is that the cost is non-zero. Packages built as if certain instruction sets are not available can suffer performance penalties as the same calculations will typically require more CPU cycles. Upstream projects may also not deliberately not target CPUs missing certain instruction sets. It is likely that additional research will be needed before we are ready to draft an RFC for this architecture that draws a line on the minimum hardware requirements. Research needed is primarily in the form of trying to build packages for v8 and figuring out which ones do not build as a result of missing instruction sets. ## Possible resolutions ### Officially support ARMv8 and ARMv8.2 packages This has the benefit of providing the broadest possible device support under the current scope (64-bitness) while also avoiding the performance penalty for v8.2+ devices. The cost is twice as many non-`any` packages to build and store. It also has the potential to get messy if certain packages are unavailable for v8 and any dependencies can't be easily adjusted to work around their absence. ### Officially support ARMv8.2 This effectively draws the line at the Raspberry Pi 5 and later devices. Cloud `aarch64` VMs (including those provided by Hetzner and AWS) use ARMv8.2+ instruction sets. An argument in favor could be made that Arch Linux provides "desktop environment" packages and if a given piece of hardware isn't being supported by upstream providers of "desktop" applications, then perhaps we shouldn't support building _any_ packages for those devices. ### Officially support ARMv8 This would provide the broadest coverage of devices but would result in performance penalties for v8.2+ devices. Ex-ante the workarounds/patches needed should also be expected to be greater than supporting v8.2 alone.