On 1 November 2017 at 20:36, Emilio G. Cota <c...@braap.org> 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
