From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755766AbcECI4p (ORCPT ); Tue, 3 May 2016 04:56:45 -0400 Received: from e06smtp09.uk.ibm.com ([195.75.94.105]:33566 "EHLO e06smtp09.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755557AbcECI4l (ORCPT ); Tue, 3 May 2016 04:56:41 -0400 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: gkurz@linux.vnet.ibm.com X-IBM-RcptTo: kvm@vger.kernel.org;linux-kernel@vger.kernel.org Date: Tue, 3 May 2016 10:56:31 +0200 From: Greg Kurz To: Cornelia Huck Cc: Paolo Bonzini , james.hogan@imgtec.com, mingo@redhat.com, linux-mips@linux-mips.org, kvm@vger.kernel.org, rkrcmar@redhat.com, linux-kernel@vger.kernel.org, David Hildenbrand , qemu-ppc@nongnu.org, Paul Mackerras , David Gibson Subject: Re: [PATCH v5 2/2] kvm: introduce KVM_MAX_VCPU_ID Message-ID: <20160503105631.71f7a01c@bahia.huguette.org> In-Reply-To: <20160503084912.2cdc42f8.cornelia.huck@de.ibm.com> References: <146221092579.32310.10051562885606992534.stgit@bahia.huguette.org> <146221113787.32310.7342723782230547207.stgit@bahia.huguette.org> <20160503084912.2cdc42f8.cornelia.huck@de.ibm.com> Organization: IBM X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16050308-0037-0000-0000-00000C9C460C Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 3 May 2016 08:49:12 +0200 Cornelia Huck wrote: > On Tue, 03 May 2016 06:52:02 +0200 > Greg Kurz wrote: > > > The KVM_MAX_VCPUS define provides the maximum number of vCPUs per guest, and > > also the upper limit for vCPU ids. This is okay for all archs except PowerPC > > which can have higher ids, depending on the cpu/core/thread topology. In the > > worst case (single threaded guest, host with 8 threads per core), it limits > > the maximum number of vCPUS to KVM_MAX_VCPUS / 8. > > > > This patch separates the vCPU numbering from the total number of vCPUs, with > > the introduction of KVM_MAX_VCPU_ID, as the maximal valid value for vCPU ids > > plus one. > > > > The corresponding KVM_CAP_MAX_VCPU_ID allows userspace to validate vCPU ids > > before passing them to KVM_CREATE_VCPU. > > > > Only PowerPC gets unlimited vCPU ids for the moment. This patch doesn't > > change anything for other archs. > > > > Suggested-by: Radim Krcmar > > Signed-off-by: Greg Kurz > > --- > > Documentation/virtual/kvm/api.txt | 10 ++++++++-- > > arch/powerpc/include/asm/kvm_host.h | 2 ++ > > arch/powerpc/kvm/powerpc.c | 3 +++ > > include/linux/kvm_host.h | 4 ++++ > > include/uapi/linux/kvm.h | 1 + > > virt/kvm/kvm_main.c | 2 +- > > 6 files changed, 19 insertions(+), 3 deletions(-) > > > > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index 23bfe1bd159c..3b4efa1c088c 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -35,6 +35,10 @@ > > > > #include > > > > +#ifndef KVM_MAX_VCPU_ID > > +#define KVM_MAX_VCPU_ID KVM_MAX_VCPUS > > As you are defining KVM_MAX_VCPU_ID in any case, would it make sense to > provide the cap in generic code? power will simply override the value. > I'll do that in v6. Thanks ! > > +#endif > > + > > /* > > * The bit 16 ~ bit 31 of kvm_memory_region::flags are internally used > > * in kvm, other bits are visible for userspace which are defined in