Re: [Qemu-devel] [PULL 00/51] tcg queued patches

[Peter Maydell]

On 1 November 2017 at 20:36, Emilio G. Cota <address@hidden> wrote:
> On Wed, Nov 01, 2017 at 18:34:23 +0100, Thomas Huth wrote:
>> Seems like something in this patch series broke a couple of ARM boards
>> (smdkc210, nuri, raspi2, xlnx-ep108 and xlnx-zcu102). With current
>> master branch, I just get this error:
>>
>> $ aarch64-softmmu/qemu-system-aarch64  -machine raspi2
>> **
>> ERROR:/home/thuth/devel/qemu/tcg/tcg.c:537:tcg_register_thread:
>> assertion failed: (n < max_cpus)
>> Aborted (core dumped)
>>
>> Could you please have a look at this?
>
> Turns out some boards initialize a fixed number of vcpus, which
> can be > max_cpus.
>
> The below fixes the issue for me, although I'm not entirely happy
> with it because if -{smp,max}_cpus < machine_class->max_cpus, some
> TCG regions will be wasted. Not a huge deal (in most cases it will be
> 2MB per unused vCPU), but a better fix might be to just honour -max_cpus
> for these boards. We might just not care enough though.

Maybe we should allow machine models to specify:
 * max_cpus (the most they can support; 1 if not set by board,
   as in current code)
 * min_cpus (the least they can support; 1 if not set by board)
 * default_cpus (what you get if you don't ask for something else;
   1 if not set by board)

Then:
 * these boards which always create a fixed number of CPUs
   should set all three to the same thing
 * boards which only create the CPUs requested by the user
   can leave them unset (as today)
 * the generic command line parsing code should stop with an
   error message if the user sets max_cpus smaller than
   the board's min_cpus setting or greater than the board's
   max_cpus, or if they set -smp to less than the board's
   min_cpus
 * the TCG code can rely on the max_cpus global being right

Incidentally every time we add a field to MachineClass we
should add a doc comment giving its semantics.

thanks
-- PMM