The following series presents cpu_enabled_map, which captures
the concept of a physically present and enabled CPU.
The complement of this map gives us present but disabled CPUs.
Perhaps the CPU was disabled by firmware for whatever reason.
For the most part, cpu_enabled_map will follow cpu_present_map.
On x86 and ia64, ACPI can tell us if a CPU is present, enabled,
or both. On those two archs, cpu_enabled_map is a subset of
cpu_present_map. All CPUs described in the MADT are now added
to cpu_present_map, but only ones with ACPI_MADT_ENABLED are
added to cpu_enabled_map.
Other archs may wish to do something similar, so some minimum
levels of support are included with this patch series, enabling
others to fill things in as desired. I certainly acknowledge
that a better job could be done.
Patch 01 introduces the actual map and interface.
Patches 02 -- 12 modify arch code in an attempt to populate the
map correctly.
Patch 12 is the most interesting one, in that we actually
demonstrate how an arch [ia64] would actually use cpu_enabled_map
to control calling cpu_up() on a given CPU.
Patch 13 fixes a potential overflow bug in ia64 ACPI code.
Patch 14 is the money patch. It demonstrates why we might
want to go through all these gyrations. Now that ia64 presents
*all* physically present CPUs in sysfs, even if they have been
disabled by firmware, we give userspace a way to poke at those
CPUs.
This is possible because present CPUs are in the ACPI namespace.
Even though we might not have a valid per_cpu pointer for a
disabled CPU (because we never called cpu_up() on it), we can
still obtain a valid ACPI handle for that CPU by walking the
namespace and executing methods underneath it.
The big picture implication is that we can allow userspace
to interact with disabled CPUs. In this particular example,
we provide a knob that lets a sysadmin schedule any present
CPU for firmware deconfiguration or enablement.
I have compile tested on:
- arm, sparc, powerpc, alpha, x86, and ia64
I have boot tested on x86 and ia64
None of my x86 platforms have firmware support for disabling
CPUs, but my ia64 ones do, so that's where I've done my most
extensive testing.
Thanks.
/ac
---
Alex Chiang (14):
ACPI: Provide /sys/devices/system/cpu/cpuN/deconfigure
[IA64] Avoid overflowing ia64_cpu_to_sapicid in acpi_map_lsapic()
[IA64] Populate and use cpu_enabled_map
x86: Populate cpu_enabled_map
[SPARC] Populate cpu_enabled_map
[SH] Populate cpu_enabled_map
[S390] Populate cpu_enabled_map
[POWERPC] Populate cpu_enabled_map
[PARISC] Populate cpu_enabled_map
[MIPS] Populate cpu_enabled_map
[ARM] Populate cpu_enabled_map
[ALPHA] Populate cpu_enabled_map
[M32R] Populate cpu_enabled_map
Introduce cpu_enabled_map and friends
arch/alpha/kernel/process.c | 2
arch/alpha/kernel/smp.c | 2
arch/arm/mach-realview/platsmp.c | 4
arch/ia64/kernel/acpi.c | 21 +-
arch/ia64/kernel/smpboot.c | 7 +
arch/m32r/kernel/smpboot.c | 1
arch/mips/kernel/smp.c | 1
arch/mips/kernel/smtc.c | 1
arch/parisc/kernel/processor.c | 1
arch/parisc/kernel/smp.c | 3
arch/powerpc/kernel/setup-common.c | 1
arch/powerpc/platforms/powermac/smp.c | 1
arch/powerpc/platforms/pseries/hotplug-cpu.c | 2
arch/s390/kernel/smp.c | 7 +
arch/sh/kernel/smp.c | 1
arch/sparc/kernel/smp.c | 1
arch/sparc64/kernel/mdesc.c | 1
arch/sparc64/kernel/smp.c | 1
arch/x86/kernel/acpi/boot.c | 7 -
arch/x86/kernel/apic_32.c | 1
arch/x86/kernel/apic_64.c | 1
arch/x86/kernel/smpboot.c | 2
arch/x86/mach-voyager/voyager_smp.c | 2
arch/x86/xen/smp.c | 1
drivers/acpi/Kconfig | 18 ++
drivers/acpi/Makefile | 4
drivers/acpi/processor_core.c | 8 +
drivers/acpi/processor_deconfigure.c | 275 ++++++++++++++++++++++++++
drivers/base/cpu.c | 9 +
include/acpi/processor.h | 6 +
include/asm-ia64/smp.h | 1
include/asm-m32r/smp.h | 1
include/linux/cpumask.h | 31 ++-
init/main.c | 1
kernel/sched.c | 16 +-
35 files changed, 415 insertions(+), 27 deletions(-)
create mode 100644 drivers/acpi/processor_deconfigure.c
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
