From: Sean Christopherson <seanjc@google.com>
To: 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,
vkuznets@redhat.com, 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: Tue, 15 Aug 2023 10:11:17 -0700 [thread overview]
Message-ID: <ZNuxtU7kxnv1L88H@google.com> (raw)
In-Reply-To: <20230815153537.113861-1-kyle.meyer@hpe.com>
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.
> arch/x86/include/asm/kvm_host.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 3bc146dfd38d..91a01fa17fa7 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -39,7 +39,11 @@
>
> #define __KVM_HAVE_ARCH_VCPU_DEBUGFS
>
> +#ifdef CONFIG_MAXSMP
> +#define KVM_MAX_VCPUS 4096
> +#else
> #define KVM_MAX_VCPUS 1024
> +#endif
Rather than tightly couple this to MAXSMP, what if we add a Kconfig? I know of
at least one scenario, SVM's AVIC/x2AVIC, where it would be desirable to configure
KVM to a much smaller maximum. The biggest downside I can think of is that KVM
selftests would need to be updated (they assume the max is >=512), and some of the
tests might be completely invalid if KVM_MAX_VCPUS is too low (<256?).
E.g.
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 60d430b4650f..8704748e35d9 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -39,7 +39,7 @@
#define __KVM_HAVE_ARCH_VCPU_DEBUGFS
-#define KVM_MAX_VCPUS 1024
+#define KVM_MAX_VCPUS CONFIG_KVM_MAX_NR_VCPUS
/*
* In x86, the VCPU ID corresponds to the APIC ID, and APIC IDs
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index ed90f148140d..b0f92eb77f78 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -151,6 +151,17 @@ config KVM_PROVE_MMU
If in doubt, say "N".
+config KVM_MAX_NR_VCPUS
+ int "Maximum vCPUs per VM"
+ default "4096" if MAXSMP
+ default "1024"
+ range 1 4096
+ depends on KVM
+ help
+ Set the maximum number of vCPUs for a single VM. Larger values
+ increase the memory footprint of each VM regardless of how many vCPUs
+ are actually created (though the memory increase is relatively small).
+
config KVM_EXTERNAL_WRITE_TRACKING
bool
next prev parent reply other threads:[~2023-08-15 17:12 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 [this message]
2023-08-17 20:23 ` Meyer, Kyle
2023-08-17 23:44 ` Sean Christopherson
2023-09-06 15:54 ` Vitaly Kuznetsov
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=ZNuxtU7kxnv1L88H@google.com \
--to=seanjc@google.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=steve.wahl@hpe.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox