Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754796AbcDYObI (ORCPT ); Mon, 25 Apr 2016 10:31:08 -0400 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:57052 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752595AbcDYObF convert rfc822-to-8bit (ORCPT ); Mon, 25 Apr 2016 10:31:05 -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: Mon, 25 Apr 2016 16:30:54 +0200 From: Greg Kurz To: Radim =?UTF-8?B?S3LEjW3DocWZ?= Cc: Paolo Bonzini , james.hogan@imgtec.com, mingo@redhat.com, linux-mips@linux-mips.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Hildenbrand , qemu-ppc@nongnu.org, Cornelia Huck , Paul Mackerras , David Gibson Subject: Re: [PATCH v4 2/2] KVM: move vcpu id checking to archs Message-ID: <20160425163054.70422eda@bahia.huguette.org> In-Reply-To: <20160425141522.GB2386@potion> References: <146124809455.32509.15232948272580716135.stgit@bahia.huguette.org> <146124811255.32509.17679765789502091772.stgit@bahia.huguette.org> <20160421160018.GA31953@potion> <20160421184500.6cb5fd8a@bahia.huguette.org> <20160421173611.GB30356@potion> <20160422112538.41b23a9d@bahia.huguette.org> <20160422134029.GE25335@potion> <20160422165024.0d85d31d@bahia.huguette.org> <20160425141522.GB2386@potion> 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=UTF-8 Content-Transfer-Encoding: 8BIT X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16042514-0013-0000-0000-00000EDA2152 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 515 Lines: 16 On Mon, 25 Apr 2016 16:15:22 +0200 Radim Krčmář wrote: > 2016-04-22 16:50+0200, Greg Kurz: > > Just to be sure I haven't missed something: > > - change the spec to introduce the MAX_VCPU_ID concept > > - update all related checks in KVM > > - provide a KVM_CAP_MAX_VCPU_ID for userspace > > That is it, thanks a lot! > > (From nitpicks that come to my mind ... MAX_VCPU_ID should not be able > to lower the VCPU_ID limit below MAX_VCPUS.) > Indeed it shouldn't. Thanks for the tip !