Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 17931
b: refs/heads/master
c: 7eb903f
h: refs/heads/master
i:
  17929: 6d13cd5
  17927: 4e53dec
v: v3
  • Loading branch information
Andi Kleen authored and Linus Torvalds committed Jan 12, 2006
1 parent f391d3f commit e63190c
Show file tree
Hide file tree
Showing 2 changed files with 22 additions and 1 deletion.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: f62a91f6911479642c0018290d4248ace4287648
refs/heads/master: 7eb903f4a5c35c8310f0aa7b0e94aae0b826d837
21 changes: 21 additions & 0 deletions trunk/Documentation/x86_64/cpu-hotplug-spec
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
Firmware support for CPU hotplug under Linux/x86-64
---------------------------------------------------

Linux/x86-64 supports CPU hotplug now. For various reasons Linux wants to
know in advance boot time the maximum number of CPUs that could be plugged
into the system. ACPI 3.0 currently has no official way to supply
this information from the firmware to the operating system.

In ACPI each CPU needs an LAPIC object in the MADT table (5.2.11.5 in the
ACPI 3.0 specification). ACPI already has the concept of disabled LAPIC
objects by setting the Enabled bit in the LAPIC object to zero.

For CPU hotplug Linux/x86-64 expects now that any possible future hotpluggable
CPU is already available in the MADT. If the CPU is not available yet
it should have its LAPIC Enabled bit set to 0. Linux will use the number
of disabled LAPICs to compute the maximum number of future CPUs.

In the worst case the user can overwrite this choice using a command line
option (additional_cpus=...), but it is recommended to supply the correct
number (or a reasonable approximation of it, with erring towards more not less)
in the MADT to avoid manual configuration.

0 comments on commit e63190c

Please sign in to comment.