* [Qemu-devel] [PATCH] pc: q35: bump max_cpus to INT32_MAX
@ 2017-03-22 15:59 Radim Krčmář
2017-03-22 16:06 ` Michael S. Tsirkin
0 siblings, 1 reply; 3+ messages in thread
From: Radim Krčmář @ 2017-03-22 15:59 UTC (permalink / raw)
To: qemu-devel
Cc: Igor Mammedov, Paolo Bonzini, Richard Henderson, Eduardo Habkost,
Michael S. Tsirkin
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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH] pc: q35: bump max_cpus to INT32_MAX
2017-03-22 15:59 [Qemu-devel] [PATCH] pc: q35: bump max_cpus to INT32_MAX Radim Krčmář
@ 2017-03-22 16:06 ` Michael S. Tsirkin
2017-03-22 16:54 ` Radim Krčmář
0 siblings, 1 reply; 3+ messages in thread
From: Michael S. Tsirkin @ 2017-03-22 16:06 UTC (permalink / raw)
To: Radim Krčmář
Cc: qemu-devel, Igor Mammedov, Paolo Bonzini, Richard Henderson,
Eduardo Habkost
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH] pc: q35: bump max_cpus to INT32_MAX
2017-03-22 16:06 ` Michael S. Tsirkin
@ 2017-03-22 16:54 ` Radim Krčmář
0 siblings, 0 replies; 3+ messages in thread
From: Radim Krčmář @ 2017-03-22 16:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: qemu-devel, Igor Mammedov, Paolo Bonzini, Richard Henderson,
Eduardo Habkost
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-22 16:54 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-22 15:59 [Qemu-devel] [PATCH] pc: q35: bump max_cpus to INT32_MAX Radim Krčmář
2017-03-22 16:06 ` Michael S. Tsirkin
2017-03-22 16:54 ` Radim Krčmář
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).