[PATCHv4 0/3] enable nr_cpus for powerpc

This topic has a very long history. It comes from Mahesh Salgaonkar For v3: https://patchwork.ozlabs.org/patch/834860/ In this series, I separate and change the mapping between cpu logical id and hwid. I hope we can acquire it for "kexec -p" Mahesh Salgaonkar (1):

[PATCHv4 3/3] ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit.

From: Mahesh Salgaonkar The kernel boot parameter 'nr_cpus=' allows one to specify number of possible cpus in the system. In the normal scenario the first cpu (cpu0) that shows up is the boot cpu and hence it gets covered under nr_cpus limit. But this assumption will

[PATCHv4 2/3] powerpc, cpu: handling the special case when boot_cpuid greater than nr_cpus

For kexec -p, after boot_cpuid is mapping into the range of [0, threads_per_core), then if nr_cpus is small, we will have the bitmap [0,..., nr_cpus, ..., boot_cpuid, ...). This patch chooses cpus inside the range of [boot_cpuid - nr_cpus +1, ..., boot_cpuid] to be online. With this patch and the

[PATCHv4 1/3] powerpc, cpu: partially unbind the mapping between cpu logical id and its seq in dt

For kexec -p, the boot cpu can be not the cpu0, this causes the problem to alloc paca[]. In theory, there is no requirement to assign cpu's logical id as its present seq by device tree. But we have something like cpu_first_thread_sibling(), which makes assumption on the mapping inside a core.

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

On 03/09/18 at 06:33pm, AKASHI Takahiro wrote: [snip] > Oops, please apply the fix below to my first patch ("kexec_file: make > an use of purgatory optional"). My screw-up is trivial here :) Wow, human eyes sometimes can not catch such issue, thanks for the fix. It works for me. > > Please