Re: [Qemu-devel] [RFC v1 PATCH 2/3] cpus: Convert cpu_index into a bitmap

[Bharata B Rao <bharata@linux.vnet.ibm.com>]

On Fri, May 08, 2015 at 11:55:00AM -0300, Eduardo Habkost wrote:
> On Fri, May 08, 2015 at 03:21:35PM +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. This patch
> > also adds corresponding instance_finalize routine if needed for these
> > CPU targets so that CPU can be marked free when it is removed.
> > 
> > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > ---
> >  exec.c                      | 37 ++++++++++++++++++++++++++++++++++---
> >  include/qom/cpu.h           |  8 ++++++++
> >  target-alpha/cpu.c          |  6 ++++++
> >  target-arm/cpu.c            |  1 +
> >  target-cris/cpu.c           |  6 ++++++
> >  target-i386/cpu.c           |  6 ++++++
> >  target-lm32/cpu.c           |  6 ++++++
> >  target-m68k/cpu.c           |  6 ++++++
> >  target-microblaze/cpu.c     |  6 ++++++
> >  target-mips/cpu.c           |  6 ++++++
> >  target-moxie/cpu.c          |  6 ++++++
> >  target-openrisc/cpu.c       |  6 ++++++
> >  target-ppc/translate_init.c |  6 ++++++
> >  target-s390x/cpu.c          |  1 +
> >  target-sh4/cpu.c            |  6 ++++++
> >  target-sparc/cpu.c          |  1 +
> >  target-tricore/cpu.c        |  5 +++++
> >  target-unicore32/cpu.c      |  6 ++++++
> >  target-xtensa/cpu.c         |  6 ++++++
> >  19 files changed, 128 insertions(+), 3 deletions(-)
> 
> Why not simply call cpu_exec_exit() on generic CPU::instance_finalize,
> to avoid forcing every architecture to call it manually? Calling
> cpu_exec_exit() twice would be harmless, anyway.

Yes cpu_exec_exit() can be called from generic CPU::instance_finalize and
it does appear harmless calling it twice but,

Can there be a situation where cpu_index freed from the first cpu_exec_exit()
call from ->unrealize() be allocated (to a different caller) again before
the 2nd call for the same CPU from CPU::instance_finalize ? If yes,
cpu_exec_exit() needs to be more intelligent than what it is currently is.

> 
> (It would just need an additional check to make sure the bit will be
> cleared only if cpu_exec_init() was really called and cpu_index was
> properly set.)

If the situation I describe above can indeed happen, then cpu_exec_exit()
needs to maintain state to safely fail the double free for the same CPU
from the same caller. I think touching all archs and adding instance_finalize
would be much more simpler, cleaner and correct. When archs want to move
cpu_exec_init() and cpu_exec_exit() to realize/unlrealize, they can do
so.

Regards,
Bharata.