1 .. SPDX-License-Identifier: GPL-2.0 2 .. _cpuhp_index: 3 4 ==================== 5 CPU Hotplug and ACPI 6 ==================== 7 8 CPU hotplug in the arm64 world is commonly used to describe the kernel taking 9 CPUs online/offline using PSCI. This document is about ACPI firmware allowing 10 CPUs that were not available during boot to be added to the system later. 11 12 ``possible`` and ``present`` refer to the state of the CPU as seen by linux. 13 14 15 CPU Hotplug on physical systems - CPUs not present at boot 16 ---------------------------------------------------------- 17 18 Physical systems need to mark a CPU that is ``possible`` but not ``present`` as 19 being ``present``. An example would be a dual socket machine, where the package 20 in one of the sockets can be replaced while the system is running. 21 22 This is not supported. 23 24 In the arm64 world CPUs are not a single device but a slice of the system. 25 There are no systems that support the physical addition (or removal) of CPUs 26 while the system is running, and ACPI is not able to sufficiently describe 27 them. 28 29 e.g. New CPUs come with new caches, but the platform's cache topology is 30 described in a static table, the PPTT. How caches are shared between CPUs is 31 not discoverable, and must be described by firmware. 32 33 e.g. The GIC redistributor for each CPU must be accessed by the driver during 34 boot to discover the system wide supported features. ACPI's MADT GICC 35 structures can describe a redistributor associated with a disabled CPU, but 36 can't describe whether the redistributor is accessible, only that it is not 37 'always on'. 38 39 arm64's ACPI tables assume that everything described is ``present``. 40 41 42 CPU Hotplug on virtual systems - CPUs not enabled at boot 43 --------------------------------------------------------- 44 45 Virtual systems have the advantage that all the properties the system will 46 ever have can be described at boot. There are no power-domain considerations 47 as such devices are emulated. 48 49 CPU Hotplug on virtual systems is supported. It is distinct from physical 50 CPU Hotplug as all resources are described as ``present``, but CPUs may be 51 marked as disabled by firmware. Only the CPU's online/offline behaviour is 52 influenced by firmware. An example is where a virtual machine boots with a 53 single CPU, and additional CPUs are added once a cloud orchestrator deploys 54 the workload. 55 56 For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware. 57 58 Virtual hotplug is implemented as a firmware policy affecting which CPUs can be 59 brought online. Firmware can enforce its policy via PSCI's return codes. e.g. 60 ``DENIED``. 61 62 The ACPI tables must describe all the resources of the virtual machine. CPUs 63 that firmware wishes to disable either from boot (or later) should not be 64 ``enabled`` in the MADT GICC structures, but should have the ``online capable`` 65 bit set, to indicate they can be enabled later. The boot CPU must be marked as 66 ``enabled``. The 'always on' GICR structure must be used to describe the 67 redistributors. 68 69 CPUs described as ``online capable`` but not ``enabled`` can be set to enabled 70 by the DSDT's Processor object's _STA method. On virtual systems the _STA method 71 must always report the CPU as ``present``. Changes to the firmware policy can 72 be notified to the OS via device-check or eject-request. 73 74 CPUs described as ``enabled`` in the static table, should not have their _STA 75 modified dynamically by firmware. Soft-restart features such as kexec will 76 re-read the static properties of the system from these static tables, and 77 may malfunction if these no longer describe the running system. Linux will 78 re-discover the dynamic properties of the system from the _STA method later 79 during boot.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.