From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEaRX-00008y-IV for qemu-devel@nongnu.org; Wed, 28 Aug 2013 03:45:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VEaRR-0005DK-I6 for qemu-devel@nongnu.org; Wed, 28 Aug 2013 03:45:31 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:57794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VEaRR-0005DA-9s for qemu-devel@nongnu.org; Wed, 28 Aug 2013 03:45:25 -0400 Date: Wed, 28 Aug 2013 03:45:22 -0400 (EDT) From: Andrew Jones Message-ID: <1172443315.2448865.1377675922559.JavaMail.root@redhat.com> In-Reply-To: <521D5298.9050504@redhat.com> References: <1377264277-23614-1-git-send-email-drjones@redhat.com> <521D5298.9050504@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: ehabkost@redhat.com, kvm@vger.kernel.org, libvir-list@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, afaerber@suse.de ----- Original Message ----- > On 08/23/2013 07:24 AM, Andrew Jones 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. > > > > v2: > > Incorporate tests for max_cpus, which specifies the maximum number > > of hotpluggable cpus. An additional note is that the message for > > the fail case was slightly changed, 'exceeds max cpus' to > > 'exceeds the maximum cpus'. If this is unacceptable change for > > users like libvirt, then I'll need to spin a v3. > > A quick grep of libvirt does not show any dependence on the particular > wording "exceeds max cpus", so you are probably fine changing that. > > What I'm more worried about is what number is libvirt supposed to show > to the end user, and should libvirt enforce the lower recommended max, > or the larger kernel absolute max? Which of the two values does the QMP > 'MachineInfo' type return in its 'cpu-max' field during the > 'query-machines' command? Should we be modifying QMP to return both > values, so that libvirt can also expose the logic to the end user of > allowing a recommended vs. larger development max? > Machine definitions maintain yet another 'max_cpus'. And it appears that qmp would return that value. It would probably be best if it returned max(qemu_machine.max_cpus, kvm_max_cpus) though. I'm starting to think that we should just keep things simple for most of the virt stack by sticking to enforcing the larger developer max. And then on a production kernel we should just compile KVM_MAX_VCPUS = KVM_SOFT_MAX_VCPUS and be done with it. With that thought, this patch could be dropped too. The alternative seems to be supporting a run-time selectable experimental mode throughout the whole virt stack. drew