Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp557895iog; Wed, 29 Jun 2022 05:54:51 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tANejJRrUboe1ah96Kej4NPTFs0yaf+qLgZuPT5iuVohgS+ZUhnAZmn20+VbeCZa9wT1Wr X-Received: by 2002:a05:6402:3227:b0:435:8e00:62b4 with SMTP id g39-20020a056402322700b004358e0062b4mr3954295eda.325.1656507291487; Wed, 29 Jun 2022 05:54:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656507291; cv=none; d=google.com; s=arc-20160816; b=xMjjxSWH3jnc8DsVbhlk8IiKf453T1UrJDXwFD9XhFN0eR9kwRnBOOmWqFE0PP1Pir griZlZf8gdyIsiZ8UTmWTWkxtgi2vkDAaJC2whiewImCcuR1PfwCdSkkXWtDPt+jwSbe SYqgmsn71Nu47ikdFjbyXiIltHZI70FMxiLEXZANQ87K8a+5VFnvxRHWuYMILkvBEcUG +5t8wPGsmFAejidMmcemnMo/bMfbPj7WoIrgar8ODq+H02/QguOJNdGhp9a08QpI7LOc ba4oGeKdRIP/efRqQaWEUPAKUF38aun4/yor3LbbKAmWtMsn66bLQQ1yr6Bk0ZwF8laD 6/tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=RMd3beZelLDV4ezdXlil9kUUgFUc4WQ7K60RuFKw/HY=; b=OoYdUpfUjXE0zMuFVzcjjeT0iSx00ZBS+gRpW7R1Mo3t/UmtyDAnNDD3HEneXjN0xB 6nYrlZc79j0SsW3rMa85Mcl5rG8SQyJc/QJ/QBM84S5M2+6n5B6xqx7G8jhzNc/FUoUG 6woQ4bDnS9JVhBtIQSRgL3TDmlQsN7Az+XuIti3AJa/D/Te7U4zCLqWK+SZBDd5uryrV V2l4qQ2Pd4ODHcALIdgYAp87+V9rRIb5LB/UILvJDe13ew8Kl4b2Y9AN0bLTn34pdGQq BWnEW6ONESzrQMvefBMzeL5CFRv5ZalAWAMV/0K6G6sRiyPkkt+ZietpYYXyKbLdjGgY dp4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=HFmBaReI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z1-20020a1709067e4100b00718d0985aa0si14991251ejr.247.2022.06.29.05.54.25; Wed, 29 Jun 2022 05:54:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=HFmBaReI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233095AbiF2Me2 (ORCPT + 99 others); Wed, 29 Jun 2022 08:34:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231551AbiF2Me0 (ORCPT ); Wed, 29 Jun 2022 08:34:26 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B94A255A0 for ; Wed, 29 Jun 2022 05:34:24 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id r20so22272263wra.1 for ; Wed, 29 Jun 2022 05:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainfault-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RMd3beZelLDV4ezdXlil9kUUgFUc4WQ7K60RuFKw/HY=; b=HFmBaReI/awGH6JxHKqA0o52Y+nCod1lVVxfWiH3shSbFiyHLla0MRYnSnu4q5JFrb pbesCQB/VAWWKhlG44+uPHWsAK8kVQwBzQKG2iqOxe0+hvAJ3XrzG+QosKPe2++K2ic9 x6jQrhQpOyizj2mujtCW7y7EZcvF14yE5o4JLM1mO0UU2x0+JKcgqxlIaN+n5s9ldGd+ 58rB9NtKG/Xcbc6qzcki4hpQhA2IJOBs0vj5LGuwCa6lBtNVuBkP+sfAb56SRs+q3TNN cYRCEV6z3ob5N4N0KzC+mlEQuemepjFmB+rKy9LXsHry+gvAQxHAx+rILCbMkFcm6XmT B/tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RMd3beZelLDV4ezdXlil9kUUgFUc4WQ7K60RuFKw/HY=; b=HbElC6HY36KVIzWdZb9B2QTzmyOBDhWKe7p4lyO3izllRfjn/m/2VeclFg0jfFNfml iKs7I0JCuqiDRxrFMkCoIWYr13ZPwllAhnro65OPbQXamOpcFXcdkYi/XduN+3Eloxdg BfGkSQR3u9+OF6wkwBdATcBbbK0/tdfdjVJak1oXIxj/UE5e9dmWx9ryoL/V0ry4q96r +inAT7Vjv8X4Um5hS/48RnUn3zhtUIt8SWXcswjsNw24ahN0GVBUcfWVb6Mgtvw++7Qa I9BOOKIX4xO6PYAojCK5NxIkEsyYeqvikvtpbMmutyki+T3uSPPEg05kPS+p5EnDS7mK iImQ== X-Gm-Message-State: AJIora/mIvfzzbLB/ty3SnDmwWw5jW2bulJ/qv6iVs7jynsbLnFGAaUJ kEwziz9d6MJQhDgyMzYzYxjF/urunteBe7L0Rg4O5g== X-Received: by 2002:a5d:4532:0:b0:21b:ab1e:e9fa with SMTP id j18-20020a5d4532000000b0021bab1ee9famr2902041wra.214.1656506062697; Wed, 29 Jun 2022 05:34:22 -0700 (PDT) MIME-Version: 1.0 References: <20220622192710.2547152-1-pbonzini@redhat.com> <20220622192710.2547152-22-pbonzini@redhat.com> In-Reply-To: <20220622192710.2547152-22-pbonzini@redhat.com> From: Anup Patel Date: Wed, 29 Jun 2022 18:04:12 +0530 Message-ID: Subject: Re: [PATCH v7 21/23] KVM: Allow for different capacities in kvm_mmu_memory_cache structs To: Paolo Bonzini Cc: "linux-kernel@vger.kernel.org List" , KVM General , Marc Zyngier , Sean Christopherson , Ben Gardon , Peter Xu , "Maciej S. Szmigiero" , "moderated list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" , "open list:KERNEL VIRTUAL MACHINE FOR MIPS (KVM/mips)" , "open list:KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)" , Peter Feiner , Lai Jiangshan , David Matlack Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 23, 2022 at 12:57 AM Paolo Bonzini wrote: > > From: David Matlack > > Allow the capacity of the kvm_mmu_memory_cache struct to be chosen at > declaration time rather than being fixed for all declarations. This will > be used in a follow-up commit to declare an cache in x86 with a capacity > of 512+ objects without having to increase the capacity of all caches in > KVM. > > This change requires each cache now specify its capacity at runtime, > since the cache struct itself no longer has a fixed capacity known at > compile time. To protect against someone accidentally defining a > kvm_mmu_memory_cache struct directly (without the extra storage), this > commit includes a WARN_ON() in kvm_mmu_topup_memory_cache(). > > In order to support different capacities, this commit changes the > objects pointer array to be dynamically allocated the first time the > cache is topped-up. > > While here, opportunistically clean up the stack-allocated > kvm_mmu_memory_cache structs in riscv and arm64 to use designated > initializers. > > No functional change intended. > > Reviewed-by: Marc Zyngier > Signed-off-by: David Matlack > Message-Id: <20220516232138.1783324-22-dmatlack@google.com> > Signed-off-by: Paolo Bonzini For KVM RISC-V Reviewed-by: Anup Patel Tested-by: Anup Patel Regards, Anup > --- > arch/arm64/kvm/mmu.c | 2 +- > arch/riscv/kvm/mmu.c | 5 +---- > include/linux/kvm_host.h | 1 + > include/linux/kvm_types.h | 6 +++++- > virt/kvm/kvm_main.c | 33 ++++++++++++++++++++++++++++++--- > 5 files changed, 38 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index f5651a05b6a8..87f1cd0df36e 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -786,7 +786,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa, > { > phys_addr_t addr; > int ret = 0; > - struct kvm_mmu_memory_cache cache = { 0, __GFP_ZERO, NULL, }; > + struct kvm_mmu_memory_cache cache = { .gfp_zero = __GFP_ZERO }; > struct kvm_pgtable *pgt = kvm->arch.mmu.pgt; > enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_DEVICE | > KVM_PGTABLE_PROT_R | > diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c > index 1c00695ebee7..081f8d2b9cf3 100644 > --- a/arch/riscv/kvm/mmu.c > +++ b/arch/riscv/kvm/mmu.c > @@ -350,10 +350,7 @@ static int gstage_ioremap(struct kvm *kvm, gpa_t gpa, phys_addr_t hpa, > int ret = 0; > unsigned long pfn; > phys_addr_t addr, end; > - struct kvm_mmu_memory_cache pcache; > - > - memset(&pcache, 0, sizeof(pcache)); > - pcache.gfp_zero = __GFP_ZERO; > + struct kvm_mmu_memory_cache pcache = { .gfp_zero = __GFP_ZERO }; > > end = (gpa + size + PAGE_SIZE - 1) & PAGE_MASK; > pfn = __phys_to_pfn(hpa); > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index a2bbdf3ab086..3554e48406e4 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -1356,6 +1356,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm); > > #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE > int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); > +int __kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int capacity, int min); > int kvm_mmu_memory_cache_nr_free_objects(struct kvm_mmu_memory_cache *mc); > void kvm_mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc); > void *kvm_mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc); > diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h > index f328a01db4fe..4d933518060f 100644 > --- a/include/linux/kvm_types.h > +++ b/include/linux/kvm_types.h > @@ -85,12 +85,16 @@ struct gfn_to_pfn_cache { > * MMU flows is problematic, as is triggering reclaim, I/O, etc... while > * holding MMU locks. Note, these caches act more like prefetch buffers than > * classical caches, i.e. objects are not returned to the cache on being freed. > + * > + * The @capacity field and @objects array are lazily initialized when the cache > + * is topped up (__kvm_mmu_topup_memory_cache()). > */ > struct kvm_mmu_memory_cache { > int nobjs; > gfp_t gfp_zero; > struct kmem_cache *kmem_cache; > - void *objects[KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE]; > + int capacity; > + void **objects; > }; > #endif > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 5b8ae83e09d7..45188d11812c 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -396,14 +396,31 @@ static inline void *mmu_memory_cache_alloc_obj(struct kvm_mmu_memory_cache *mc, > return (void *)__get_free_page(gfp_flags); > } > > -int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min) > +int __kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int capacity, int min) > { > + gfp_t gfp = GFP_KERNEL_ACCOUNT; > void *obj; > > if (mc->nobjs >= min) > return 0; > - while (mc->nobjs < ARRAY_SIZE(mc->objects)) { > - obj = mmu_memory_cache_alloc_obj(mc, GFP_KERNEL_ACCOUNT); > + > + if (unlikely(!mc->objects)) { > + if (WARN_ON_ONCE(!capacity)) > + return -EIO; > + > + mc->objects = kvmalloc_array(sizeof(void *), capacity, gfp); > + if (!mc->objects) > + return -ENOMEM; > + > + mc->capacity = capacity; > + } > + > + /* It is illegal to request a different capacity across topups. */ > + if (WARN_ON_ONCE(mc->capacity != capacity)) > + return -EIO; > + > + while (mc->nobjs < mc->capacity) { > + obj = mmu_memory_cache_alloc_obj(mc, gfp); > if (!obj) > return mc->nobjs >= min ? 0 : -ENOMEM; > mc->objects[mc->nobjs++] = obj; > @@ -411,6 +428,11 @@ int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min) > return 0; > } > > +int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min) > +{ > + return __kvm_mmu_topup_memory_cache(mc, KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE, min); > +} > + > int kvm_mmu_memory_cache_nr_free_objects(struct kvm_mmu_memory_cache *mc) > { > return mc->nobjs; > @@ -424,6 +446,11 @@ void kvm_mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc) > else > free_page((unsigned long)mc->objects[--mc->nobjs]); > } > + > + kvfree(mc->objects); > + > + mc->objects = NULL; > + mc->capacity = 0; > } > > void *kvm_mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc) > -- > 2.31.1 > >