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ář <rkrc...@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