From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 3/3] kvm-s390: implement KVM_CAP_MAX_VCPUS Date: Mon, 30 Apr 2012 22:00:41 -0300 Message-ID: <20120501010041.GA9609@amt.cnet> References: <1335252285-54213-1-git-send-email-borntraeger@de.ibm.com> <1335252285-54213-4-git-send-email-borntraeger@de.ibm.com> <4F969734.6080401@redhat.com> <4F96A0F4.1010205@de.ibm.com> <4F96A434.7030203@redhat.com> <20120501005147.GA9621@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christian Borntraeger , Carsten Otte , Alexander Graf , Jens Freimann , Cornelia Huck , Heiko Carstens , Martin Schwidefsky , Heinz Graalfs , KVM To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11331 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754956Ab2EABIH (ORCPT ); Mon, 30 Apr 2012 21:08:07 -0400 Content-Disposition: inline In-Reply-To: <20120501005147.GA9621@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Apr 30, 2012 at 09:51:47PM -0300, Marcelo Tosatti wrote: > On Tue, Apr 24, 2012 at 04:01:40PM +0300, Avi Kivity wrote: > > On 04/24/2012 03:47 PM, Christian Borntraeger wrote: > > > > btw, a better place might be in kvm_devel_ioctl_check_extension_generic(). > > > > > > Possibly yes. Dont know if there are architecture specific reasons to use > > > something different than KVM_MAX_VCPUS. > > > > Okay, I'll fold the implementations unless something prevents it (unlikely). > > KVM_CAP_NR_VCPUS = "recommended max_vcpus" > KVM_CAP_MAX_VCPUS = "maximum possible value for max_vcpus" > > (commit 8c3ba334f8588e1d5) > > CAP_NR_VCPUS is architecture dependent (depends on state of scability, > testing, etc). Both KVM_CAP_MAX_VCPUS and KVM_CAP_NR_VCPUS are architecture dependent. Christian, you probably want to implement both (skipping this one patch), applied remainder, thanks.