From: Igor Mammedov <imammedo@redhat.com>
To: Dario Faggioli <dfaggioli@suse.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"eduardo@habkost.net" <eduardo@habkost.net>,
"mst@redhat.com" <mst@redhat.com>,
"marcel.apfelbaum@gmail.com" <marcel.apfelbaum@gmail.com>,
"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: How about increasing max_cpus for q35 ?
Date: Fri, 11 Nov 2022 11:33:00 +0100 [thread overview]
Message-ID: <20221111113300.7dd39cdd@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <c705d0d8d6ed1a520b1ff92cb2f83fef19522d30.camel@suse.com>
On Wed, 9 Nov 2022 13:36:07 +0000
Dario Faggioli <dfaggioli@suse.com> wrote:
> Hello,
>
> Sorry for the potentially naive question, but I'm not clear what the
> process would be if, say, I'd like to raise the number of maximum CPUs
> a q35 VM can have.
>
> So, right now we have:
>
> void pc_q35_2_7_machine_options(MachineClass *m) {
> ...
> m->max_cpus = 255;
> }
>
> And:
>
> void pc_q35_machine_options(MachineClass *m)
> {
> ...
> m->max_cpus = 288;
> }
>
> Focusing on the latter, it comes from this commit:
>
> https://gitlab.com/qemu-project/qemu/-/commit/00d0f9fd6602a27b204f672ef5bc8e69736c7ff1
>
> pc: q35: Bump max_cpus to 288
>
> Along with it for machine versions 2.7 and older keep
> it at 255.
>
> So, it was 255 and is now 288. This seems to me to be there since QEMU
> 2.8.0.
>
> Now, as far as I understand, KVM can handle 1024, at least since this
> commit (and a couple of other related ones):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=074c82c8f7cf8a46c3b81965f122599e3a133450
> "kvm: x86: Increase MAX_VCPUS to 1024"
>
> Which basically does:
>
> -#define KVM_MAX_VCPUS 288
> +#define KVM_MAX_VCPUS 1024
>
> And it's included in kernels >= 5.15.
>
> So, what's the correct way of bumping up the limit again? Just changing
> that assignment in pc_q35_machine_options()
that and preserve 288 limit for existing machine types.
Basically the same as above QEMU commit with difference
that pc_q35_2_8_machine_options() should be replaced by
7.2 equivalent.
PS:
we are still missing OVMF support for 1024,
but it's being worked on.
> ? Or do we want a new
> version of the machine type or something like that?
>
> Thanks and Regards
next prev parent reply other threads:[~2022-11-11 10:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 13:36 How about increasing max_cpus for q35 ? Dario Faggioli
2022-11-11 10:33 ` Igor Mammedov [this message]
2022-11-11 10:47 ` Daniel P. Berrangé
2022-11-11 13:40 ` Igor Mammedov
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=20221111113300.7dd39cdd@imammedo.users.ipa.redhat.com \
--to=imammedo@redhat.com \
--cc=dfaggioli@suse.com \
--cc=eduardo@habkost.net \
--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).