xref: /OK3568_Linux_fs/kernel/Documentation/x86/x86_64/cpu-hotplug-spec.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593Smuzhiyun.. SPDX-License-Identifier: GPL-2.0
2*4882a593Smuzhiyun
3*4882a593Smuzhiyun===================================================
4*4882a593SmuzhiyunFirmware support for CPU hotplug under Linux/x86-64
5*4882a593Smuzhiyun===================================================
6*4882a593Smuzhiyun
7*4882a593SmuzhiyunLinux/x86-64 supports CPU hotplug now. For various reasons Linux wants to
8*4882a593Smuzhiyunknow in advance of boot time the maximum number of CPUs that could be plugged
9*4882a593Smuzhiyuninto the system. ACPI 3.0 currently has no official way to supply
10*4882a593Smuzhiyunthis information from the firmware to the operating system.
11*4882a593Smuzhiyun
12*4882a593SmuzhiyunIn ACPI each CPU needs an LAPIC object in the MADT table (5.2.11.5 in the
13*4882a593SmuzhiyunACPI 3.0 specification).  ACPI already has the concept of disabled LAPIC
14*4882a593Smuzhiyunobjects by setting the Enabled bit in the LAPIC object to zero.
15*4882a593Smuzhiyun
16*4882a593SmuzhiyunFor CPU hotplug Linux/x86-64 expects now that any possible future hotpluggable
17*4882a593SmuzhiyunCPU is already available in the MADT. If the CPU is not available yet
18*4882a593Smuzhiyunit should have its LAPIC Enabled bit set to 0. Linux will use the number
19*4882a593Smuzhiyunof disabled LAPICs to compute the maximum number of future CPUs.
20*4882a593Smuzhiyun
21*4882a593SmuzhiyunIn the worst case the user can overwrite this choice using a command line
22*4882a593Smuzhiyunoption (additional_cpus=...), but it is recommended to supply the correct
23*4882a593Smuzhiyunnumber (or a reasonable approximation of it, with erring towards more not less)
24*4882a593Smuzhiyunin the MADT to avoid manual configuration.
25