On Wed, 11 May 2016 16:00:04 +0200 Greg Kurz <gk...@linux.vnet.ibm.com> wrote:
> Some systems can already provide more than 255 hardware threads. > > Bumping the QEMU limit to 1024 seems reasonable: > - it has no visible overhead in top > - the limit itself has no effect on hot paths > > Signed-off-by: Greg Kurz <gk...@linux.vnet.ibm.com> > --- > > This was tested with a pseries guest only. I'd like to know if it is okay > for other platforms. #git grep MAX_CPUMASK_BITS ... hw/arm/virt.c: mc->max_cpus = MAX_CPUMASK_BITS; hw/ppc/spapr.c: mc->max_cpus = MAX_CPUMASK_BITS; ... you probably don't want to change all those to 1024, see/review a similar patch where I bump it upto 288 bits https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg01101.html in addition where does 1024 come from? is pseries capable to provide that many CPUs? > > include/sysemu/sysemu.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h > index 38fb3cad35e1..89d742caa477 100644 > --- a/include/sysemu/sysemu.h > +++ b/include/sysemu/sysemu.h > @@ -185,7 +185,7 @@ extern int mem_prealloc; > * > * Note that cpu->get_arch_id() may be larger than MAX_CPUMASK_BITS. > */ > -#define MAX_CPUMASK_BITS 255 > +#define MAX_CPUMASK_BITS 1024 > > #define MAX_OPTION_ROMS 16 > typedef struct QEMUOptionRom { >