From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] pc: q35: bump max_cpus to INT32_MAX
Date: Wed, 22 Mar 2017 18:06:29 +0200 [thread overview]
Message-ID: <20170322180319-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20170322155906.10679-1-rkrcmar@redhat.com>
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
next prev parent reply other threads:[~2017-03-22 16:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2017-03-22 16:54 ` Radim Krčmář
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=20170322180319-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkrcmar@redhat.com \
--cc=rth@twiddle.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.