From: "Andreas Färber" <afaerber@suse.de>
To: Eduardo Habkost <ehabkost@redhat.com>, Andrew Jones <drjones@redhat.com>
Cc: kvm@vger.kernel.org, gleb@redhat.com, libvir-list@redhat.com,
mtosatti@redhat.com,
qemu-devel developers <qemu-devel@nongnu.org>,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH] kvm: warn if num cpus is greater than num recommended
Date: Thu, 22 Aug 2013 18:21:19 +0200 [thread overview]
Message-ID: <52163A7F.7020402@suse.de> (raw)
In-Reply-To: <F7B7360F-AAFE-40E5-9F60-E754CB3368EA@redhat.com>
Am 22.08.2013 18:12, schrieb Eduardo Habkost:
>
> On 22/08/2013, at 12:39, Andrew Jones <drjones@redhat.com> wrote:
>
>> The comment in kvm_max_vcpus() states that it's using the recommended
>> procedure from the kernel API documentation to get the max number
>> of vcpus that kvm supports. It is, but by always returning the
>> maximum number supported. The maximum number should only be used
>> for development purposes. qemu should check KVM_CAP_NR_VCPUS for
>> the recommended number of vcpus. This patch adds a warning if a user
>> specifies a number of cpus between the recommended and max.
>>
>> Signed-off-by: Andrew Jones <drjones@redhat.com>
>
> CCing libvir-list. It is probably interesting for libvirt to expose or warn about the recommended VCPU limit somehow, and in this case a simple warning on stderr won't be enough.
>
>> ---
>> kvm-all.c | 45 +++++++++++++++++++++++++++------------------
>> 1 file changed, 27 insertions(+), 18 deletions(-)
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index 716860f617455..9092e13ae60ea 100644
>> --- a/kvm-all.c
>> +++ b/kvm-all.c
>> @@ -1313,24 +1313,24 @@ static int kvm_irqchip_create(KVMState *s)
>> return 0;
>> }
>>
>> -static int kvm_max_vcpus(KVMState *s)
>> +/* Find number of supported CPUs using the recommended
>> + * procedure from the kernel API documentation to cope with
>> + * older kernels that may be missing capabilities.
>> + */
>> +static int kvm_recommended_vcpus(KVMState *s)
>> {
>> int ret;
>>
>> - /* Find number of supported CPUs using the recommended
>> - * procedure from the kernel API documentation to cope with
>> - * older kernels that may be missing capabilities.
>> - */
>> - ret = kvm_check_extension(s, KVM_CAP_MAX_VCPUS);
>> - if (ret) {
>> - return ret;
>> - }
>> ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
>> - if (ret) {
>> - return ret;
>> - }
>> + return (ret) ? ret : 4;
>> +}
>>
>> - return 4;
>> +static int kvm_max_vcpus(KVMState *s)
>> +{
>> + int ret;
>> +
>> + ret = kvm_check_extension(s, KVM_CAP_MAX_VCPUS);
>> + return (ret) ? ret : kvm_recommended_vcpus(s);
>> }
>>
>> int kvm_init(void)
>> @@ -1383,12 +1383,21 @@ int kvm_init(void)
>> goto err;
>> }
>>
>> - max_vcpus = kvm_max_vcpus(s);
>> + max_vcpus = kvm_recommended_vcpus(s);
>> if (smp_cpus > max_vcpus) {
>> - ret = -EINVAL;
>> - fprintf(stderr, "Number of SMP cpus requested (%d) exceeds max cpus "
>> - "supported by KVM (%d)\n", smp_cpus, max_vcpus);
>> - goto err;
>> + fprintf(stderr,
>> + "Warning: Number of SMP cpus requested (%d) exceeds "
>> + "recommended cpus supported by KVM (%d)\n",
>> + smp_cpus, max_vcpus);
>> +
>> + max_vcpus = kvm_max_vcpus(s);
>> + if (smp_cpus > max_vcpus) {
>> + ret = -EINVAL;
>> + fprintf(stderr, "Number of SMP cpus requested (%d) exceeds "
>> + "max cpus supported by KVM (%d)\n",
>> + smp_cpus, max_vcpus);
>> + goto err;
>> + }
Should at least the fatal one use the new error_report()?
>> }
>>
>> s->vmfd = kvm_ioctl(s, KVM_CREATE_VM, 0);
I notice that only checks in kvm_init() based on smp_cpus are touched
herein. Should we add similar checks to CPU hot-add code and thus
possibly move that into some per-vCPU code path?
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-08-22 16:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-22 15:39 [PATCH] kvm: warn if num cpus is greater than num recommended Andrew Jones
2013-08-22 15:39 ` [Qemu-devel] " Andrew Jones
2013-08-22 16:12 ` Eduardo Habkost
2013-08-22 16:12 ` [Qemu-devel] " Eduardo Habkost
2013-08-22 16:21 ` Andreas Färber [this message]
2013-08-23 11:33 ` Andrew Jones
2013-08-23 11:33 ` Andrew Jones
2013-08-26 7:43 ` Paolo Bonzini
2013-08-26 7:43 ` Paolo Bonzini
2013-08-26 8:00 ` Andrew Jones
2013-08-26 8:00 ` Andrew Jones
2013-08-22 16:38 ` Paolo Bonzini
2013-08-22 16:38 ` [Qemu-devel] " Paolo Bonzini
2013-08-23 11:35 ` Andrew Jones
2013-08-23 11:35 ` Andrew Jones
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=52163A7F.7020402@suse.de \
--to=afaerber@suse.de \
--cc=drjones@redhat.com \
--cc=ehabkost@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=libvir-list@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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.