QEMU does not allocate based on machine's max_cpus, but only uses it to
limit the maximum selected by user and the actual limit of VCPUs is
enfoced by other components:
 - machine without vIOMMU ends at 255 VCPUs
 - TCG currently doesn't support x2APIC, so it also ends below 256
 - KVM with vIOMMU cannot exceed the KVM limit (currently 288)

Using a big value should bring no drawbacks and the benefit is that
components (especially out-of-tree KVM) can bump their limits without
touching machine's max_cpus.

max_cpus is unsigned, but it is treated as signed at least in printf and
the other two billion VCPU won't be needed for a while, so we can ignore
possible bugs by using signed max.

Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
---
  Should the 2.9 machine type still have 288?
---
 hw/i386/pc_q35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index dd792a8547b3..3d5710ca20e0 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -298,7 +298,7 @@ static void pc_q35_machine_options(MachineClass *m)
     m->default_display = "std";
     m->no_floppy = 1;
     m->has_dynamic_sysbus = true;
-    m->max_cpus = 288;
+    m->max_cpus = INT32_MAX;
 }
 
 static void pc_q35_2_9_machine_options(MachineClass *m)
@@ -314,6 +314,7 @@ static void pc_q35_2_8_machine_options(MachineClass *m)
 {
     pc_q35_2_9_machine_options(m);
     m->alias = NULL;
+    m->max_cpus = 288;
     SET_MACHINE_COMPAT(m, PC_COMPAT_2_8);
 }
 
-- 
2.12.0

On Wed, Mar 22, 2017 at 04:59:06PM +0100, Radim Krčmář wrote:
> QEMU does not allocate based on machine's max_cpus, but only uses it to
> limit the maximum selected by user and the actual limit of VCPUs is
> enfoced by other components:
>  - machine without vIOMMU ends at 255 VCPUs
>  - TCG currently doesn't support x2APIC, so it also ends below 256
>  - KVM with vIOMMU cannot exceed the KVM limit (currently 288)
> 
> Using a big value should bring no drawbacks and the benefit is that
> components (especially out-of-tree KVM) can bump their limits without
> touching machine's max_cpus.
> 
> max_cpus is unsigned, but it is treated as signed at least in printf and
> the other two billion VCPU won't be needed for a while, so we can ignore
> possible bugs by using signed max.
> 
> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
> ---
>   Should the 2.9 machine type still have 288?

It doesn't look like a bugfix to me.
So if we can defer past 2.9 that would be best IMO.


> ---
>  hw/i386/pc_q35.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index dd792a8547b3..3d5710ca20e0 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -298,7 +298,7 @@ static void pc_q35_machine_options(MachineClass *m)
>      m->default_display = "std";
>      m->no_floppy = 1;
>      m->has_dynamic_sysbus = true;
> -    m->max_cpus = 288;
> +    m->max_cpus = INT32_MAX;
>  }
>  
>  static void pc_q35_2_9_machine_options(MachineClass *m)
> @@ -314,6 +314,7 @@ static void pc_q35_2_8_machine_options(MachineClass *m)
>  {
>      pc_q35_2_9_machine_options(m);
>      m->alias = NULL;
> +    m->max_cpus = 288;
>      SET_MACHINE_COMPAT(m, PC_COMPAT_2_8);
>  }
>  
> -- 
> 2.12.0

2017-03-22 18:06+0200, Michael S. Tsirkin:
> On Wed, Mar 22, 2017 at 04:59:06PM +0100, Radim Krčmář wrote:
>> QEMU does not allocate based on machine's max_cpus, but only uses it to
>> limit the maximum selected by user and the actual limit of VCPUs is
>> enfoced by other components:
>>  - machine without vIOMMU ends at 255 VCPUs
>>  - TCG currently doesn't support x2APIC, so it also ends below 256
>>  - KVM with vIOMMU cannot exceed the KVM limit (currently 288)
>> 
>> Using a big value should bring no drawbacks and the benefit is that
>> components (especially out-of-tree KVM) can bump their limits without
>> touching machine's max_cpus.
>> 
>> max_cpus is unsigned, but it is treated as signed at least in printf and
>> the other two billion VCPU won't be needed for a while, so we can ignore
>> possible bugs by using signed max.
>> 
>> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
>> ---
>>   Should the 2.9 machine type still have 288?
> 
> It doesn't look like a bugfix to me.
> So if we can defer past 2.9 that would be best IMO.

Sure, I'll wait until the 2.10 machine type pops up.

Thanks.