From patchwork Wed Dec 7 08:29:24 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sasha Levin X-Patchwork-Id: 129916 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 097DE1007D5 for ; Wed, 7 Dec 2011 19:29:47 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753610Ab1LGI3q (ORCPT ); Wed, 7 Dec 2011 03:29:46 -0500 Received: from mail-ey0-f174.google.com ([209.85.215.174]:42940 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752242Ab1LGI3p (ORCPT ); Wed, 7 Dec 2011 03:29:45 -0500 Received: by eaak14 with SMTP id k14so209876eaa.19 for ; Wed, 07 Dec 2011 00:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=9C19Rl2/7K+JPchbfLtKl1p3L1V+I2H6lxO0jsNRrQo=; b=nKmvrTmsmTfjKn31WbMeNREJ+Rk+2e7W5bgJfeMJOf0fxkcABwLmmSmIH52sacVD+6 CnD2q6FGEnIlMJUlXu5uSOW6rZvFJutmDFwilkQLvxec42VrTUQyCb0gHVR9ckSkhR3k GI3l7ARAOdxYzXD6hE+VD59dkT2WO8NK/1Ijg= Received: by 10.213.10.193 with SMTP id q1mr3204844ebq.115.1323246583910; Wed, 07 Dec 2011 00:29:43 -0800 (PST) Received: from [172.16.1.240] (safend2.bb.netvision.net.il. [212.143.23.59]) by mx.google.com with ESMTPS id 58sm3110863eet.11.2011.12.07.00.29.42 (version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 00:29:43 -0800 (PST) Message-ID: <1323246564.4009.2.camel@lappy> Subject: Re: [PATCH 07/28] kvm tools: Move 'kvm__recommended_cpus' to arch-specific code From: Sasha Levin To: Matt Evans Cc: Alexander Graf , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" Date: Wed, 07 Dec 2011 10:29:24 +0200 In-Reply-To: <4EDF158E.1050607@ozlabs.org> References: <4EDD8E73.8040505@ozlabs.org> <1323159616.3882.7.camel@lappy> <4EDF04F4.40805@ozlabs.org> <1323239695.8489.25.camel@lappy> <4EDF138E.6040703@ozlabs.org> <4EDF158E.1050607@ozlabs.org> X-Mailer: Evolution 3.2.2 Mime-Version: 1.0 Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org On Wed, 2011-12-07 at 18:28 +1100, Matt Evans wrote: > On 07/12/11 18:24, Alexander Graf wrote: > > > > On 07.12.2011, at 08:19, Matt Evans wrote: > > > >> On 07/12/11 17:34, Sasha Levin wrote: > >>> On Wed, 2011-12-07 at 17:17 +1100, Matt Evans wrote: > >>>> On 06/12/11 19:20, Sasha Levin wrote: > >>>>> Why is it getting moved out of generic code? > >>>>> > >>>>> This is used to determine the maximum amount of vcpus supported by the > >>>>> host for a single guest, and as far as I know KVM_CAP_NR_VCPUS and > >>>>> KVM_CAP_MAX_VCPUS are not arch specific. > >>>> > >>>> I checked api.txt and you're right, it isn't arch-specific. I assumed it was, > >>>> because PPC KVM doesn't support it ;-) I've dropped this patch and in its place > >>>> implemented the api.txt suggestion of "if KVM_CAP_NR_VCPUS fails, use 4" instead > >>>> of die(); you'll see that when I repost. > >>>> > >>>> This will have the effect of PPC being limited to 4 CPUs until the kernel > >>>> supports that CAP. (I'll see about this part too.) > >>> > >>> I went to look at which limitation PPC places on amount of vcpus in > >>> guest, and saw this in kvmppc_core_vcpu_create() in the book3s code: > >>> > >>> vcpu = kvmppc_core_vcpu_create(kvm, id); > >>> vcpu->arch.wqp = &vcpu->wq; > >>> if (!IS_ERR(vcpu)) > >>> kvmppc_create_vcpu_debugfs(vcpu, id); > >>> > >>> This is wrong, right? The VCPU is dereferenced before actually checking > >>> that it's not an error. > >> > >> Yeah, that's b0rk. Alex, a patch below. :) > > > > Thanks :). Will apply asap but don't have a real keyboard today :). > > Ha! Voice control on your phone, what could go wrong? > > > I suppose this is stable material? > > Good idea, (and if we're formal, > Signed-off-by: Matt Evans > ). I suppose no one's seen a vcpu fail to be created, yet. I also got another one, but it's **completely untested** (not even compiled). Alex, Matt, any chance one of you can loan a temporary ppc shell for the upcoming tests of KVM tool/ppc KVM? Acked-by: Paul Mackerras --- From: Sasha Levin Date: Wed, 7 Dec 2011 10:24:56 +0200 Subject: [PATCH] KVM: PPC: Use the vcpu kmem_cache when allocating new VCPUs Currently the code kzalloc()s new VCPUs instead of using the kmem_cache which is created when KVM is initialized. Modify it to allocate VCPUs from that kmem_cache. Signed-off-by: Sasha Levin --- arch/powerpc/kvm/book3s_hv.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 0cb137a..e309099 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -411,7 +411,7 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id) goto out; err = -ENOMEM; - vcpu = kzalloc(sizeof(struct kvm_vcpu), GFP_KERNEL); + vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL); if (!vcpu) goto out; @@ -463,7 +463,7 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id) return vcpu; free_vcpu: - kfree(vcpu); + kmem_cache_free(kvm_vcpu_cache, vcpu); out: return ERR_PTR(err); } @@ -471,7 +471,7 @@ out: void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu) { kvm_vcpu_uninit(vcpu); - kfree(vcpu); + kmem_cache_free(kvm_vcpu_cache, vcpu); } static void kvmppc_set_timer(struct kvm_vcpu *vcpu)