qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Ani Sinha <anisinha@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <eduardo@habkost.net>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Julia Suvorova <jusual@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH] pc: q35: Bump max_cpus to 4096
Date: Fri, 8 Dec 2023 12:57:59 +0000	[thread overview]
Message-ID: <ZXMS15q8x5-cWPA3@redhat.com> (raw)
In-Reply-To: <20231208122611.32311-1-anisinha@redhat.com>

On Fri, Dec 08, 2023 at 05:56:11PM +0530, Ani Sinha wrote:
> Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up to 4096 vCPUs")
> Linux kernel can support upto a maximum number of 4096 vCPUS when MAXSMP is
> enabled in the kernel. So bump up the max_cpus value for q35 machines versions
> 8.3 and newer to 4096. Older q35 machines versions 8.2 and older continue to
> support 1024 maximum vcpus as before.
> 
> If KVM is not able to support the specified number of vcpus, QEMU would
> return the following error messages:
> 
> $ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 4096
> qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (4096) exceeds the recommended cpus supported by KVM (12)
> Number of SMP cpus requested (4096) exceeds the maximum cpus supported by KVM (1024)
> 
> Cc: Daniel P. Berrangé <berrange@redhat.com>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Julia Suvorova <jusual@redhat.com>
> Signed-off-by: Ani Sinha <anisinha@redhat.com>
> ---
>  hw/i386/pc_q35.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)

What testing has been done to confirm if QEMU is actually capable of
booting a guest with this CPU count, either UEFI or SeaBIOS or both ?

Historically every time we wanted to raise max cpus we've seen limits
or scalability problems that needed fixing first. The previous bump to
1024 had been implicitly proven via downstream testing we had done in
RHEL, and had required the switch to SMBIOS v3 entrypoint.

> 
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 4f3e5412f6..2ed57814e1 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -375,7 +375,7 @@ static void pc_q35_machine_options(MachineClass *m)
>      m->default_nic = "e1000e";
>      m->default_kernel_irqchip_split = false;
>      m->no_floppy = 1;
> -    m->max_cpus = 1024;
> +    m->max_cpus = 4096;
>      m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
>      machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
>      machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
> @@ -383,12 +383,22 @@ static void pc_q35_machine_options(MachineClass *m)
>      machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
>  }
>  
> -static void pc_q35_8_2_machine_options(MachineClass *m)
> +static void pc_q35_8_3_machine_options(MachineClass *m)
>  {
>      pc_q35_machine_options(m);
>      m->alias = "q35";
>  }
>  
> +DEFINE_Q35_MACHINE(v8_3, "pc-q35-8.3", NULL,
> +                   pc_q35_8_3_machine_options);
> +
> +static void pc_q35_8_2_machine_options(MachineClass *m)
> +{
> +    pc_q35_8_3_machine_options(m);
> +    m->alias = NULL;
> +    m->max_cpus = 1024;
> +}
> +
>  DEFINE_Q35_MACHINE(v8_2, "pc-q35-8.2", NULL,
>                     pc_q35_8_2_machine_options);
>  
> @@ -396,7 +406,6 @@ static void pc_q35_8_1_machine_options(MachineClass *m)
>  {
>      PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>      pc_q35_8_2_machine_options(m);
> -    m->alias = NULL;
>      pcmc->broken_32bit_mem_addr_check = true;
>      compat_props_add(m->compat_props, hw_compat_8_1, hw_compat_8_1_len);
>      compat_props_add(m->compat_props, pc_compat_8_1, pc_compat_8_1_len);
> -- 
> 2.42.0
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2023-12-08 12:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08 12:26 [PATCH] pc: q35: Bump max_cpus to 4096 Ani Sinha
2023-12-08 12:57 ` Daniel P. Berrangé [this message]
2023-12-08 14:03   ` Ani Sinha
2023-12-11  5:57 ` Thomas Huth
2023-12-14  4:31   ` Ani Sinha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXMS15q8x5-cWPA3@redhat.com \
    --to=berrange@redhat.com \
    --cc=anisinha@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=jusual@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).