On Thu, May 21, 2015 at 10:32:07AM +0530, Bharata B Rao wrote: > Currently CPUState.cpu_index is monotonically increasing and a newly > created CPU always gets the next higher index. The next available > index is calculated by counting the existing number of CPUs. This is > fine as long as we only add CPUs, but there are architectures which > are starting to support CPU removal too. For an architecture like PowerPC > which derives its CPU identifier (device tree ID) from cpu_index, the > existing logic of generating cpu_index values causes problems. > > With the currently proposed method of handling vCPU removal by parking > the vCPU fd in QEMU > (Ref: http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg02604.html), > generating cpu_index this way will not work for PowerPC. > > This patch changes the way cpu_index is handed out by maintaining > a bit map of the CPUs that tracks both addition and removal of CPUs. > > The CPU bitmap allocation logic is part of cpu_exec_init() which is > called by instance_init routines of various CPU targets. Newly added > cpu_exec_exit() API handles the deallocation part and this routine is > called from generic CPU::instance_finalize(). > > Note: This new CPU enumeration is for !CONFIG_USER_ONLY only. > CONFIG_USER_ONLY continues to have the old enumeration logic. > > Signed-off-by: Bharata B Rao <bhar...@linux.vnet.ibm.com> > Reviewed-by: Eduardo Habkost <ehabk...@redhat.com>
Reviewed-by: David Gibson <da...@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpGYPucPQM8D.pgp
Description: PGP signature
