Re: [Qemu-devel] [RFC v0 PATCH] cpus: Convert cpu_index into a bitmap

["Andreas Färber" <afaerber@suse.de>]

Am 13.03.2015 um 12:56 schrieb Bharata B Rao:
> From: Bharata B Rao <bharata.rao@gmail.com>
> 
> 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.
> 
> I am not sure if this is the right and an acceptable approach. The
> alternative is to do something similar for PowerPC alone and not
> depend on cpu_index.
> 
> I have tested this with out-of-the-tree patches for CPU hot plug and
> removal on x86 and sPAPR PowerPC.
> 
> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> ---
>  exec.c                      | 39 +++++++++++++++++++++++++++++----------
>  include/exec/exec-all.h     |  1 +
>  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, 116 insertions(+), 10 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index e97071a..7760f2d 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -530,21 +530,40 @@ void tcg_cpu_address_space_init(CPUState *cpu, AddressSpace *as)
>  }
>  #endif
>  
> +static DECLARE_BITMAP(cpu_index_map, MAX_CPUMASK_BITS);

I don't see this constant being defined in this patch. How large is it?
I wonder whether this might be stolen from an x86 ACPI/NUMA context and
forced onto all architectures now?

> +
> +#ifdef CONFIG_USER_ONLY
> +int max_cpus = 1; /* TODO: Check if this is correct ? */

This strikes me as wrong, as forking will create a copy of the initial
CPUState, see cpu_copy(). The cpu_index might get overwritten inside the
CPUState, not sure about that, but this here is global state.

Can't we just keep the current code for CONFIG_USER_ONLY and skip all
the bitmap functions?

> +#endif
> +
> +static int cpu_get_free_index(void)
> +{
> +    int cpu = find_first_zero_bit(cpu_index_map, max_cpus);
> +
> +    if (cpu == max_cpus) {
> +        fprintf(stderr, "WARNING: qemu: Trying to use more "
> +                        "CPUs than allowed max of %d\n", max_cpus);

This is a bad API. :) If we can't handle it, use an Error** errp
argument to pass that info outwards. Imagine this happening from QMP
device-add, then this warning will go unnoticed on stderr.

(Also, error_report() would use the real executable name.)

> +        return max_cpus;
> +    } else {
> +        bitmap_set(cpu_index_map, cpu, 1);
> +        return cpu;
> +    }
> +}
> +
> +void cpu_exec_exit(CPUState *cpu)
> +{
> +    bitmap_clear(cpu_index_map, cpu->cpu_index, 1);
> +}
> +
>  void cpu_exec_init(CPUArchState *env)
[snip]

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)