From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [PATCH 3/3] kvm-s390: implement KVM_CAP_MAX_VCPUS
Date: Tue, 24 Apr 2012 14:47:48 +0200
Message-ID: <4F96A0F4.1010205@de.ibm.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Marcelo Tossati <mtosatti@redhat.com>,
	Carsten Otte <cotte@de.ibm.com>,
	Alexander Graf <agraf@suse.de>,
	Jens Freimann <jfrei@linux.vnet.ibm.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:33332 "EHLO
	e06smtp11.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753967Ab2DXMrw (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 24 Apr 2012 08:47:52 -0400
Received: from /spool/local
	by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
	for <kvm@vger.kernel.org> from <borntraeger@de.ibm.com>;
	Tue, 24 Apr 2012 13:47:51 +0100
Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247])
	by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3OClkK22220064
	for <kvm@vger.kernel.org>; Tue, 24 Apr 2012 13:47:46 +0100
Received: from d06av12.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av12.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3OCljic022129
	for <kvm@vger.kernel.org>; Tue, 24 Apr 2012 06:47:46 -0600
In-Reply-To: <4F969734.6080401@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

>> @@ -136,6 +136,9 @@ int kvm_dev_ioctl_check_extension(long ext)
>>  	case KVM_CAP_SYNC_REGS:
>>  		r = 1;
>>  		break;
>> +	case KVM_CAP_NR_VCPUS:
>> +		r = KVM_MAX_VCPUS;
>> +		break;
>>  	default:
>>  		r = 0;
>>  	}
> 
> This looks like a bugfix, but having survived so long without it, I
> imagine it's not urgent for 3.4.

Right it is not urgent.

> 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.