From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Sean Christopherson <seanjc@google.com>, Kyle Meyer <kyle.meyer@hpe.com>
Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hasen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
dmatlack@google.com, russ.anderson@hpe.com,
dimitri.sivanich@hpe.com, steve.wahl@hpe.com
Subject: Re: [PATCH] KVM: x86: Increase KVM_MAX_VCPUS to 4096
Date: Wed, 06 Sep 2023 17:54:30 +0200 [thread overview]
Message-ID: <87v8cns3ex.fsf@redhat.com> (raw)
In-Reply-To: <ZNuxtU7kxnv1L88H@google.com>
Sean Christopherson <seanjc@google.com> writes:
> On Tue, Aug 15, 2023, Kyle Meyer wrote:
>> Increase KVM_MAX_VCPUS to 4096 when MAXSMP is enabled.
>>
>> Notable changes (when MAXSMP is enabled):
>>
>> * KMV_MAX_VCPUS will increase from 1024 to 4096.
>> * KVM_MAX_VCPU_IDS will increase from 4096 to 16384.
>> * KVM_HV_MAX_SPARSE_VCPU_SET_BITS will increase from 16 to 64.
>> * CPUID[HYPERV_CPUID_IMPLEMENT_LIMITS (0x40000005)].EAX will now be 4096.
>>
>> * struct kvm will increase from 39408 B to 39792 B.
>> * struct kvm_ioapic will increase from 5240 B to 19064 B.
>>
>> * The following (on-stack) bitmaps will increase from 128 B to 512 B:
>> * dest_vcpu_bitmap in kvm_irq_delivery_to_apic.
>> * vcpu_mask in kvm_hv_flush_tlb.
>> * vcpu_bitmap in ioapic_write_indirect.
>> * vp_bitmap in sparse_set_to_vcpu_mask.
>>
>> Signed-off-by: Kyle Meyer <kyle.meyer@hpe.com>
>> ---
>> Virtual machines with 4096 virtual CPUs have been created on 32 socket
>> Cascade Lake and Sapphire Rapids systems.
>>
>> 4096 is the current maximum value because of the Hyper-V TLFS. See
>> BUILD_BUG_ON in arch/x86/kvm/hyperv.c, commit 79661c3, and Vitaly's
>> comment on https://lore.kernel.org/all/87r136shcc.fsf@redhat.com.
>
> Mostly out of curiosity, do you care about Hyper-V support? If not, at some
> point it'd probably be worth exploring a CONFIG_KVM_HYPERV option to allow
> disabling KVM's Hyper-V support at compile time so that we're not bound by the
> restrictions of the TLFS.
>
(sorry for necroposting)
While adding CONFIG_KVM_HYPERV to disable all-things-Hyper-V may make
sense for some deployments (and as we already have CONFIG_KVM_XEN), I
don't think we should forbid KVM_MAX_VCPUS > 4096 when it is enabled:
'general purpose' (distro) kernels are used both for hosting large Linux
guests and Windows guests. Instead, I'd suggest we define
KVM_MAX_HV_VCPUS as MIN(KVM_MAX_VCPUS, 4096) and then e.g. fail
KVM_SET_CPUID[,2] if we already have > 4096 vCPUs + fail
kvm_arch_vcpu_create() if we already have something-hyperv enabled on
the already created vCPUs.
--
Vitaly
next prev parent reply other threads:[~2023-09-06 15:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 15:35 [PATCH] KVM: x86: Increase KVM_MAX_VCPUS to 4096 Kyle Meyer
2023-08-15 17:11 ` Sean Christopherson
2023-08-17 20:23 ` Meyer, Kyle
2023-08-17 23:44 ` Sean Christopherson
2023-09-06 15:54 ` Vitaly Kuznetsov [this message]
2023-09-08 17:44 ` Sean Christopherson
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=87v8cns3ex.fsf@redhat.com \
--to=vkuznets@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hasen@linux.intel.com \
--cc=dimitri.sivanich@hpe.com \
--cc=dmatlack@google.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=kyle.meyer@hpe.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=russ.anderson@hpe.com \
--cc=seanjc@google.com \
--cc=steve.wahl@hpe.com \
--cc=tglx@linutronix.de \
--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.