mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-04 09:59:32 +00:00
156 lines
6.2 KiB
ReStructuredText
156 lines
6.2 KiB
ReStructuredText
![]() |
======================
|
||
|
Asymmetric 32-bit SoCs
|
||
|
======================
|
||
|
|
||
|
Author: Will Deacon <will@kernel.org>
|
||
|
|
||
|
This document describes the impact of asymmetric 32-bit SoCs on the
|
||
|
execution of 32-bit (``AArch32``) applications.
|
||
|
|
||
|
Date: 2021-05-17
|
||
|
|
||
|
Introduction
|
||
|
============
|
||
|
|
||
|
Some Armv9 SoCs suffer from a big.LITTLE misfeature where only a subset
|
||
|
of the CPUs are capable of executing 32-bit user applications. On such
|
||
|
a system, Linux by default treats the asymmetry as a "mismatch" and
|
||
|
disables support for both the ``PER_LINUX32`` personality and
|
||
|
``execve(2)`` of 32-bit ELF binaries, with the latter returning
|
||
|
``-ENOEXEC``. If the mismatch is detected during late onlining of a
|
||
|
64-bit-only CPU, then the onlining operation fails and the new CPU is
|
||
|
unavailable for scheduling.
|
||
|
|
||
|
Surprisingly, these SoCs have been produced with the intention of
|
||
|
running legacy 32-bit binaries. Unsurprisingly, that doesn't work very
|
||
|
well with the default behaviour of Linux.
|
||
|
|
||
|
It seems inevitable that future SoCs will drop 32-bit support
|
||
|
altogether, so if you're stuck in the unenviable position of needing to
|
||
|
run 32-bit code on one of these transitionary platforms then you would
|
||
|
be wise to consider alternatives such as recompilation, emulation or
|
||
|
retirement. If neither of those options are practical, then read on.
|
||
|
|
||
|
Enabling kernel support
|
||
|
=======================
|
||
|
|
||
|
Since the kernel support is not completely transparent to userspace,
|
||
|
allowing 32-bit tasks to run on an asymmetric 32-bit system requires an
|
||
|
explicit "opt-in" and can be enabled by passing the
|
||
|
``allow_mismatched_32bit_el0`` parameter on the kernel command-line.
|
||
|
|
||
|
For the remainder of this document we will refer to an *asymmetric
|
||
|
system* to mean an asymmetric 32-bit SoC running Linux with this kernel
|
||
|
command-line option enabled.
|
||
|
|
||
|
Userspace impact
|
||
|
================
|
||
|
|
||
|
32-bit tasks running on an asymmetric system behave in mostly the same
|
||
|
way as on a homogeneous system, with a few key differences relating to
|
||
|
CPU affinity.
|
||
|
|
||
|
sysfs
|
||
|
-----
|
||
|
|
||
|
The subset of CPUs capable of running 32-bit tasks is described in
|
||
|
``/sys/devices/system/cpu/aarch32_el0`` and is documented further in
|
||
|
``Documentation/ABI/testing/sysfs-devices-system-cpu``.
|
||
|
|
||
|
**Note:** CPUs are advertised by this file as they are detected and so
|
||
|
late-onlining of 32-bit-capable CPUs can result in the file contents
|
||
|
being modified by the kernel at runtime. Once advertised, CPUs are never
|
||
|
removed from the file.
|
||
|
|
||
|
``execve(2)``
|
||
|
-------------
|
||
|
|
||
|
On a homogeneous system, the CPU affinity of a task is preserved across
|
||
|
``execve(2)``. This is not always possible on an asymmetric system,
|
||
|
specifically when the new program being executed is 32-bit yet the
|
||
|
affinity mask contains 64-bit-only CPUs. In this situation, the kernel
|
||
|
determines the new affinity mask as follows:
|
||
|
|
||
|
1. If the 32-bit-capable subset of the affinity mask is not empty,
|
||
|
then the affinity is restricted to that subset and the old affinity
|
||
|
mask is saved. This saved mask is inherited over ``fork(2)`` and
|
||
|
preserved across ``execve(2)`` of 32-bit programs.
|
||
|
|
||
|
**Note:** This step does not apply to ``SCHED_DEADLINE`` tasks.
|
||
|
See `SCHED_DEADLINE`_.
|
||
|
|
||
|
2. Otherwise, the cpuset hierarchy of the task is walked until an
|
||
|
ancestor is found containing at least one 32-bit-capable CPU. The
|
||
|
affinity of the task is then changed to match the 32-bit-capable
|
||
|
subset of the cpuset determined by the walk.
|
||
|
|
||
|
3. On failure (i.e. out of memory), the affinity is changed to the set
|
||
|
of all 32-bit-capable CPUs of which the kernel is aware.
|
||
|
|
||
|
A subsequent ``execve(2)`` of a 64-bit program by the 32-bit task will
|
||
|
invalidate the affinity mask saved in (1) and attempt to restore the CPU
|
||
|
affinity of the task using the saved mask if it was previously valid.
|
||
|
This restoration may fail due to intervening changes to the deadline
|
||
|
policy or cpuset hierarchy, in which case the ``execve(2)`` continues
|
||
|
with the affinity unchanged.
|
||
|
|
||
|
Calls to ``sched_setaffinity(2)`` for a 32-bit task will consider only
|
||
|
the 32-bit-capable CPUs of the requested affinity mask. On success, the
|
||
|
affinity for the task is updated and any saved mask from a prior
|
||
|
``execve(2)`` is invalidated.
|
||
|
|
||
|
``SCHED_DEADLINE``
|
||
|
------------------
|
||
|
|
||
|
Explicit admission of a 32-bit deadline task to the default root domain
|
||
|
(e.g. by calling ``sched_setattr(2)``) is rejected on an asymmetric
|
||
|
32-bit system unless admission control is disabled by writing -1 to
|
||
|
``/proc/sys/kernel/sched_rt_runtime_us``.
|
||
|
|
||
|
``execve(2)`` of a 32-bit program from a 64-bit deadline task will
|
||
|
return ``-ENOEXEC`` if the root domain for the task contains any
|
||
|
64-bit-only CPUs and admission control is enabled. Concurrent offlining
|
||
|
of 32-bit-capable CPUs may still necessitate the procedure described in
|
||
|
`execve(2)`_, in which case step (1) is skipped and a warning is
|
||
|
emitted on the console.
|
||
|
|
||
|
**Note:** It is recommended that a set of 32-bit-capable CPUs are placed
|
||
|
into a separate root domain if ``SCHED_DEADLINE`` is to be used with
|
||
|
32-bit tasks on an asymmetric system. Failure to do so is likely to
|
||
|
result in missed deadlines.
|
||
|
|
||
|
Cpusets
|
||
|
-------
|
||
|
|
||
|
The affinity of a 32-bit task on an asymmetric system may include CPUs
|
||
|
that are not explicitly allowed by the cpuset to which it is attached.
|
||
|
This can occur as a result of the following two situations:
|
||
|
|
||
|
- A 64-bit task attached to a cpuset which allows only 64-bit CPUs
|
||
|
executes a 32-bit program.
|
||
|
|
||
|
- All of the 32-bit-capable CPUs allowed by a cpuset containing a
|
||
|
32-bit task are offlined.
|
||
|
|
||
|
In both of these cases, the new affinity is calculated according to step
|
||
|
(2) of the process described in `execve(2)`_ and the cpuset hierarchy is
|
||
|
unchanged irrespective of the cgroup version.
|
||
|
|
||
|
CPU hotplug
|
||
|
-----------
|
||
|
|
||
|
On an asymmetric system, the first detected 32-bit-capable CPU is
|
||
|
prevented from being offlined by userspace and any such attempt will
|
||
|
return ``-EPERM``. Note that suspend is still permitted even if the
|
||
|
primary CPU (i.e. CPU 0) is 64-bit-only.
|
||
|
|
||
|
KVM
|
||
|
---
|
||
|
|
||
|
Although KVM will not advertise 32-bit EL0 support to any vCPUs on an
|
||
|
asymmetric system, a broken guest at EL1 could still attempt to execute
|
||
|
32-bit code at EL0. In this case, an exit from a vCPU thread in 32-bit
|
||
|
mode will return to host userspace with an ``exit_reason`` of
|
||
|
``KVM_EXIT_FAIL_ENTRY`` and will remain non-runnable until successfully
|
||
|
re-initialised by a subsequent ``KVM_ARM_VCPU_INIT`` operation.
|