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.
© 2016 - 2024 Red Hat, Inc.