[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YZZ1W+YxagvG1EMM@google.com>
Date: Thu, 18 Nov 2021 15:46:35 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Juergen Gross <jgross@...e.com>
Cc: kvm@...r.kernel.org, x86@...nel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v3 4/4] x86/kvm: add boot parameter for setting max
number of vcpus per guest
On Thu, Nov 18, 2021, Juergen Gross wrote:
> On 18.11.21 16:05, Sean Christopherson wrote:
> > Which is a good segue into pointing out that if a module param is added, it needs
> > to be sanity checked against a KVM-defined max. The admin may be trusted to some
> > extent, but there is zero reason to let userspace set max_vcspus to 4 billion.
> > At that point, it really is just a param vs. capability question.
>
> I agree. Capping it at e.g. 65536 would probably be a good idea.
Any reason to choose 65536 in particular? Why not cap it at the upper limit of
NR_CPUS_RANGE_END / MAXSMP, which is currently 8192?
Powered by blists - more mailing lists