Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S975415AbdDXRD6 (ORCPT ); Mon, 24 Apr 2017 13:03:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33516 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S975397AbdDXRDl (ORCPT ); Mon, 24 Apr 2017 13:03:41 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 715C5B5928 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=rkrcmar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 715C5B5928 Date: Mon, 24 Apr 2017 19:03:34 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Christoffer Dall , Marc Zyngier , Paolo Bonzini , Christian Borntraeger , Cornelia Huck , James Hogan , Paul Mackerras , Alexander Graf Subject: Re: [PATCH 0/4] KVM: add KVM_CREATE_VM2 to allow dynamic kvm->vcpus array Message-ID: <20170424170333.GC5713@potion> References: <20170413201951.11939-1-rkrcmar@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 24 Apr 2017 17:03:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1270 Lines: 31 2017-04-18 13:11+0200, David Hildenbrand: > On 13.04.2017 22:19, Radim Krčmář wrote: >> The basic idea is to let userspace provide the desired maximal number of >> VCPUs and allocate only necessary memory for them. >> >> The goal is to freeze KVM_MAX_VCPUS at its current level and only increase the > > KVM_MAX_VCPUS might still increase e.g. if hw support for more VCPUs is > comming. This patch wanted to make KVM_MAX_VCPUS just a compatibility option for old userspaces and not looked at in new ones, so we wouldn't have to touch it from now on. >> new KVM_MAX_CONFIGURABLE_VCPUS, probably directly to INT_MAX/KVM_VCPU_ID, so we >> don't have to worry about it for a while. >> >> PPC should be interested in this as they set KVM_MAX_VCPUS to NR_CPUS >> and probably waste few pages for every guest this way. > > As we just store pointers, this should be a maximum of 4 pages for ppc > (4k pages). Is this really worth yet another VM creation ioctl? Is there > not a nicer way to handle this internally? > > An alternative might be to simply realloc the array when it reaches a > certain size (on VCPU creation, maybe protecting the pointer via rcu). > But not sure if something like that could work. Good point. I'll cover it in the next email. Thanks.