On Sunday 21 February 2010, Brian King wrote: > On 02/21/2010 01:18 PM, Pavel Machek wrote: > > On Sun 2010-02-21 10:32:02, Brian King wrote: > >> > >> Rather than calling disable_nonboot_cpus and enable_nonboot_cpus > >> directly, wrapper the calls in a weak arch_suspend_disable_nonboot_cpus > >> and arch_suspend_enable_nonboot_cpus that can be overridden by > >> architectures that require different handling of suspending processors > >> at suspend time than these functions provide. This is needed to enable > >> suspend/resume on IBM Power servers. > > > > This needs *way* better explanation. Like: why do power servers > > require special handling? What else is disable_nonboot_cpus used for? > > disable_nonboot_cpus ends up calling _cpu_down, which is also used in > the CPU hotplug path. > > The issue is essentially that on Power servers, the state that a CPU > needs to be in when hotplug removing it is different than the state it > needs to be in for suspend. > > Here is the way that suspend works on Power servers. For each CPU, we > must make a call to the hypervisor (H_JOIN). For all but the last CPU, > this call does not return. For the last CPU, it will return with a > response indicating it is the last hardware thread. At that point, we > need to make a different call (ibm,suspend-me) to the hypervisor to > indicate we are suspending the partition. When the partition resumes, > the CPU thread that made the ibm,suspend-me call will wake up. It then > makes a call to the hypevisor (H_PROD) for each other CPU to wake up the > other CPUs. > > So, for Power, the arch_suspend_disable_nonboot_cpus implementation will > call H_JOIN for all other CPUs. Then the suspend enter call just calls > ibm,suspend-me to suspend the partition. On resume, > arch_suspend_enable_nonboot_cpus sends the H_PROD to each CPU, waking it up. > > Adding these arch hooks seemed like the cleanest way to accomplish all this. I'm not a big fan of __attribute__ ((weak)), though. While we already use that in the suspend code, I'm not particularly comfortable with it. Have you considered any alternative approaches? Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
