From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Juergen Gross <jgross@suse.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
linux-doc@vger.kernel.org, kvm@vger.kernel.org,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH 6/6] x86/kvm: add boot parameter for setting max number of vcpus per guest
Date: Fri, 03 Sep 2021 09:40:53 +0200 [thread overview]
Message-ID: <87lf4em7i2.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <bb4ebe24-1de5-82b8-001d-1c0f9f28861b@suse.com>
Juergen Gross <jgross@suse.com> writes:
> On 14.07.21 15:21, Vitaly Kuznetsov wrote:
>> Juergen Gross <jgross@suse.com> writes:
>>
>>> On 14.07.21 13:45, Vitaly Kuznetsov wrote:
>>>
>>>> Personally, I'd vote for introducing a 'ratio' parameter then so
>>>> generally users will only have to set 'kvm.max_vcpus'.
>>>
>>> Okay.
>>>
>>> Default '4' then? Or '2 ^ (topology_levels - 2)' (assuming a
>>> topology_level of 3 on Intel: thread/core/socket and 4 on EPYC:
>>> thread/core/package/socket).
>>
>> I'd suggest we default to '4' for both Intel and AMD as we haven't given
>> up completely on cross-vendor VMs (running AMD VMs on Intel CPUs and
>> vice versa). It would be great to leave a comment where the number comes
>> from of course.
>>
>
> Thinking more about it I believe it would be better to make the
> parameter something like "additional vcpu-id bits" with a default of
> topology_levels - 2 (cross-vendor VMs are so special that I think the
> need to specify another value explicitly in this case is acceptable).
>
> Reasons are:
>
> - the ability to specify factor values not being a power of 2 is weird
> - just specifying the additional number of bits would lead to compatible
> behavior (e.g. a max vcpu-id of 1023 with max_vcpus being 288 and the
> default value of 1)
> - the max vcpu-id should (normally) be 2^n - 1
Sounds good to me!
Also, there's an ongoing work to raise the default KVM_MAX_VCPUS number
by Eduardo (Cc):
https://lore.kernel.org/kvm/20210831204535.1594297-1-ehabkost@redhat.com/
It would be great if you could unify your efforts)
--
Vitaly
next prev parent reply other threads:[~2021-09-03 7:41 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-01 15:40 [PATCH 0/6] x86/kvm: add boot parameters for max vcpu configs Juergen Gross
2021-07-01 15:40 ` Juergen Gross
2021-07-01 15:40 ` Juergen Gross
2021-07-01 15:41 ` [PATCH 1/6] x86/kvm: fix vcpu-id indexed array sizes Juergen Gross
2021-09-03 15:28 ` Eduardo Habkost
2021-07-01 15:41 ` [PATCH 2/6] x86/kvm: remove non-x86 stuff from arch/x86/kvm/ioapic.h Juergen Gross
2021-07-01 15:41 ` [PATCH 3/6] x86/kvm: add boot parameter for maximum vcpu-id Juergen Gross
2021-07-01 15:41 ` [PATCH 4/6] x86/kvm: introduce per cpu vcpu masks Juergen Gross
2021-07-26 13:32 ` Paolo Bonzini
2021-07-26 13:38 ` Juergen Gross
2021-07-01 15:41 ` [PATCH 5/6] kvm: allocate vcpu pointer array separately Juergen Gross
2021-07-01 15:41 ` Juergen Gross
2021-07-01 15:41 ` Juergen Gross
2021-07-26 13:40 ` Paolo Bonzini
2021-07-26 13:40 ` Paolo Bonzini
2021-07-26 13:40 ` Paolo Bonzini
2021-07-26 13:46 ` Juergen Gross
2021-07-26 13:46 ` Juergen Gross
2021-07-26 13:46 ` Juergen Gross
2021-07-26 13:57 ` Marc Zyngier
2021-07-26 13:57 ` Marc Zyngier
2021-07-26 13:57 ` Marc Zyngier
2021-07-01 15:41 ` [PATCH 6/6] x86/kvm: add boot parameter for setting max number of vcpus per guest Juergen Gross
2021-07-14 11:15 ` Vitaly Kuznetsov
2021-07-14 11:24 ` Juergen Gross
2021-07-14 11:45 ` Vitaly Kuznetsov
2021-07-14 13:04 ` Juergen Gross
2021-07-14 13:21 ` Vitaly Kuznetsov
2021-09-03 7:01 ` Juergen Gross
2021-09-03 7:40 ` Vitaly Kuznetsov [this message]
2021-07-26 13:41 ` [PATCH 0/6] x86/kvm: add boot parameters for max vcpu configs Paolo Bonzini
2021-07-26 13:41 ` Paolo Bonzini
2021-07-26 13:41 ` Paolo Bonzini
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=87lf4em7i2.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=ehabkost@redhat.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.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 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.