From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Date: Thu, 11 Jun 2020 07:59:05 +0000 Subject: Re: [PATCH 17/21] KVM: arm64: Use common code's approach for __GFP_ZERO with memory caches Message-Id: <6cc08074c289cbea7b9c1deeaf18c63f@kernel.org> List-Id: References: <20200605213853.14959-1-sean.j.christopherson@intel.com> <20200605213853.14959-18-sean.j.christopherson@intel.com> In-Reply-To: <20200605213853.14959-18-sean.j.christopherson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Sean Christopherson Cc: Paul Mackerras , Christian Borntraeger , Janosch Frank , Paolo Bonzini , James Morse , Julien Thierry , Suzuki K Poulose , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Feiner , Peter Shier , Junaid Shahid , Ben Gardon , Christoffer Dall Hi Sean, On 2020-06-05 22:38, Sean Christopherson wrote: > Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to > make > the struct and its usage compatible with the common 'struct > kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code > churn when arm64 moves to the common implementation in a future patch, > at > the cost of temporarily having somewhat silly code. > > No functional change intended. > > Signed-off-by: Sean Christopherson > --- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/arm.c | 2 ++ > arch/arm64/kvm/mmu.c | 5 +++-- > 3 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h > b/arch/arm64/include/asm/kvm_host.h > index abbdf9703e20..2385dede96e0 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -105,6 +105,7 @@ struct kvm_arch { > */ > struct kvm_mmu_memory_cache { > int nobjs; > + gfp_t gfp_zero; > void *objects[KVM_NR_MEM_OBJS]; > }; > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 45276ed50dd6..4c98c6b4d850 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -270,6 +270,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > vcpu->arch.target = -1; > bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES); > > + vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO; > + > /* Set up the timer */ > kvm_timer_vcpu_init(vcpu); > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index 9398b66f8a87..688213ef34f0 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -131,7 +131,8 @@ static int mmu_topup_memory_cache(struct > kvm_mmu_memory_cache *cache, int min) > if (cache->nobjs >= min) > return 0; > while (cache->nobjs < ARRAY_SIZE(cache->objects)) { > - page = (void *)__get_free_page(GFP_PGTABLE_USER); > + page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT | This is definitely a change in the way we account for guest page tables allocation, although I find it bizarre that not all architectures account for it the same way. It seems logical to me that nested page tables would be accounted against userspace, but I'm willing to be educated on the matter. Another possibility is that depending on the context, some allocations should be accounted on either the kernel or userspace (NV on arm64 could definitely do something like that). If that was the case, maybe moving most of the GFP_* flags into the per-cache flags, and have the renaming that Ben suggested earlier. Thanks, M. -- Jazz is not dead. It just smells funny... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5B17C433E1 for ; Thu, 11 Jun 2020 07:59:12 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 5B7222072F for ; Thu, 11 Jun 2020 07:59:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="xdnE9ijS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5B7222072F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id F2C764B1C9; Thu, 11 Jun 2020 03:59:11 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnV25wm3ZpuJ; Thu, 11 Jun 2020 03:59:10 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1FFAC4B1BA; Thu, 11 Jun 2020 03:59:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CF8E04B1BA for ; Thu, 11 Jun 2020 03:59:08 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbvNgKnSQx4f for ; Thu, 11 Jun 2020 03:59:07 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id B2ABC4B153 for ; Thu, 11 Jun 2020 03:59:07 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A277B204EA; Thu, 11 Jun 2020 07:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591862346; bh=OosHKHNgy/JfsuiXlWm6kqNlEzxuPgPk1Y8ZZaJeWD0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xdnE9ijSYCm2ieKcA6MjTtuO04MHTQe1Et0EXVKYQCTKFPlQEVb9Yfj8kMl8AR13w Qa+QrSTirgnpvN11t74TOELy0TkE+PQGhIX4EOiSYHH4YRZ7TbRRaDjLYoA1zHsodf +Qk2xXT4keuJXovgH5hLfKz2s8TnNRSdO4NRUwV4= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjI77-0021Wl-9L; Thu, 11 Jun 2020 08:59:05 +0100 MIME-Version: 1.0 Date: Thu, 11 Jun 2020 08:59:05 +0100 From: Marc Zyngier To: Sean Christopherson Subject: Re: [PATCH 17/21] KVM: arm64: Use common code's approach for __GFP_ZERO with memory caches In-Reply-To: <20200605213853.14959-18-sean.j.christopherson@intel.com> References: <20200605213853.14959-1-sean.j.christopherson@intel.com> <20200605213853.14959-18-sean.j.christopherson@intel.com> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <6cc08074c289cbea7b9c1deeaf18c63f@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: sean.j.christopherson@intel.com, paulus@ozlabs.org, borntraeger@de.ibm.com, frankja@linux.ibm.com, pbonzini@redhat.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, david@redhat.com, cohuck@redhat.com, imbrenda@linux.ibm.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org, pfeiner@google.com, pshier@google.com, junaids@google.com, bgardon@google.com, christoffer.dall@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Wanpeng Li , kvm@vger.kernel.org, David Hildenbrand , linux-kernel@vger.kernel.org, Paul Mackerras , Ben Gardon , Claudio Imbrenda , kvmarm@lists.cs.columbia.edu, Janosch Frank , Joerg Roedel , Christian Borntraeger , Junaid Shahid , kvm-ppc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jim Mattson , Cornelia Huck , Peter Shier , linux-mips@vger.kernel.org, Paolo Bonzini , Vitaly Kuznetsov , Peter Feiner X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Sean, On 2020-06-05 22:38, Sean Christopherson wrote: > Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to > make > the struct and its usage compatible with the common 'struct > kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code > churn when arm64 moves to the common implementation in a future patch, > at > the cost of temporarily having somewhat silly code. > > No functional change intended. > > Signed-off-by: Sean Christopherson > --- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/arm.c | 2 ++ > arch/arm64/kvm/mmu.c | 5 +++-- > 3 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h > b/arch/arm64/include/asm/kvm_host.h > index abbdf9703e20..2385dede96e0 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -105,6 +105,7 @@ struct kvm_arch { > */ > struct kvm_mmu_memory_cache { > int nobjs; > + gfp_t gfp_zero; > void *objects[KVM_NR_MEM_OBJS]; > }; > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 45276ed50dd6..4c98c6b4d850 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -270,6 +270,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > vcpu->arch.target = -1; > bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES); > > + vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO; > + > /* Set up the timer */ > kvm_timer_vcpu_init(vcpu); > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index 9398b66f8a87..688213ef34f0 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -131,7 +131,8 @@ static int mmu_topup_memory_cache(struct > kvm_mmu_memory_cache *cache, int min) > if (cache->nobjs >= min) > return 0; > while (cache->nobjs < ARRAY_SIZE(cache->objects)) { > - page = (void *)__get_free_page(GFP_PGTABLE_USER); > + page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT | This is definitely a change in the way we account for guest page tables allocation, although I find it bizarre that not all architectures account for it the same way. It seems logical to me that nested page tables would be accounted against userspace, but I'm willing to be educated on the matter. Another possibility is that depending on the context, some allocations should be accounted on either the kernel or userspace (NV on arm64 could definitely do something like that). If that was the case, maybe moving most of the GFP_* flags into the per-cache flags, and have the renaming that Ben suggested earlier. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55B40C433DF for ; Thu, 11 Jun 2020 07:59:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 30C162072F for ; Thu, 11 Jun 2020 07:59:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591862348; bh=OosHKHNgy/JfsuiXlWm6kqNlEzxuPgPk1Y8ZZaJeWD0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=jWuUqlI71eROfltOO9qzZsARGJIeISEu9GNR1Prqa4Gomxv0XTdnB+lOwI2ULMV8z hPtjCJga9NcTQcVfdsZU6ZIwVTMSVcGleUqooicLmM48G1TwPmajm9VVWwvW+KXAvx hIqC6utKwlozkvsqjruBmgOnlq9d/bkpU1TshkM8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726880AbgFKH7I (ORCPT ); Thu, 11 Jun 2020 03:59:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:45596 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726716AbgFKH7H (ORCPT ); Thu, 11 Jun 2020 03:59:07 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A277B204EA; Thu, 11 Jun 2020 07:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591862346; bh=OosHKHNgy/JfsuiXlWm6kqNlEzxuPgPk1Y8ZZaJeWD0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xdnE9ijSYCm2ieKcA6MjTtuO04MHTQe1Et0EXVKYQCTKFPlQEVb9Yfj8kMl8AR13w Qa+QrSTirgnpvN11t74TOELy0TkE+PQGhIX4EOiSYHH4YRZ7TbRRaDjLYoA1zHsodf +Qk2xXT4keuJXovgH5hLfKz2s8TnNRSdO4NRUwV4= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjI77-0021Wl-9L; Thu, 11 Jun 2020 08:59:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 11 Jun 2020 08:59:05 +0100 From: Marc Zyngier To: Sean Christopherson Cc: Paul Mackerras , Christian Borntraeger , Janosch Frank , Paolo Bonzini , James Morse , Julien Thierry , Suzuki K Poulose , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Feiner , Peter Shier , Junaid Shahid , Ben Gardon , Christoffer Dall Subject: Re: [PATCH 17/21] KVM: arm64: Use common code's approach for __GFP_ZERO with memory caches In-Reply-To: <20200605213853.14959-18-sean.j.christopherson@intel.com> References: <20200605213853.14959-1-sean.j.christopherson@intel.com> <20200605213853.14959-18-sean.j.christopherson@intel.com> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <6cc08074c289cbea7b9c1deeaf18c63f@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: sean.j.christopherson@intel.com, paulus@ozlabs.org, borntraeger@de.ibm.com, frankja@linux.ibm.com, pbonzini@redhat.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, david@redhat.com, cohuck@redhat.com, imbrenda@linux.ibm.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org, pfeiner@google.com, pshier@google.com, junaids@google.com, bgardon@google.com, christoffer.dall@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org Hi Sean, On 2020-06-05 22:38, Sean Christopherson wrote: > Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to > make > the struct and its usage compatible with the common 'struct > kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code > churn when arm64 moves to the common implementation in a future patch, > at > the cost of temporarily having somewhat silly code. > > No functional change intended. > > Signed-off-by: Sean Christopherson > --- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/arm.c | 2 ++ > arch/arm64/kvm/mmu.c | 5 +++-- > 3 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h > b/arch/arm64/include/asm/kvm_host.h > index abbdf9703e20..2385dede96e0 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -105,6 +105,7 @@ struct kvm_arch { > */ > struct kvm_mmu_memory_cache { > int nobjs; > + gfp_t gfp_zero; > void *objects[KVM_NR_MEM_OBJS]; > }; > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 45276ed50dd6..4c98c6b4d850 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -270,6 +270,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > vcpu->arch.target = -1; > bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES); > > + vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO; > + > /* Set up the timer */ > kvm_timer_vcpu_init(vcpu); > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index 9398b66f8a87..688213ef34f0 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -131,7 +131,8 @@ static int mmu_topup_memory_cache(struct > kvm_mmu_memory_cache *cache, int min) > if (cache->nobjs >= min) > return 0; > while (cache->nobjs < ARRAY_SIZE(cache->objects)) { > - page = (void *)__get_free_page(GFP_PGTABLE_USER); > + page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT | This is definitely a change in the way we account for guest page tables allocation, although I find it bizarre that not all architectures account for it the same way. It seems logical to me that nested page tables would be accounted against userspace, but I'm willing to be educated on the matter. Another possibility is that depending on the context, some allocations should be accounted on either the kernel or userspace (NV on arm64 could definitely do something like that). If that was the case, maybe moving most of the GFP_* flags into the per-cache flags, and have the renaming that Ben suggested earlier. Thanks, M. -- Jazz is not dead. It just smells funny... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7C60C433DF for ; Thu, 11 Jun 2020 07:59:11 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B0168207C3 for ; Thu, 11 Jun 2020 07:59:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Jmq4OYgb"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="xdnE9ijS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B0168207C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qo9snNpqec5Hhfki0CPrcIktryethqtvJr0CnQ4mUuI=; b=Jmq4OYgbHH6qHa22RRNkd5+PK qdQM+1lRvZ+cKuPMBP/JWs6jW1BDHJJe9C4f4l0o1jrhXfVqNYASH1VMLJD5jeC1tkdFTjnCEf4ri 0GZwX78+ql1iapSD95Hiq2IU3TKQ6dpCIa90SfcQEW51bzaizOr83YWk8xNWOHIMwPx/TLSz3Qi4b hu5nJnB7Mj0PrfXeG1ujIDuo0p8gm8uCFQ5VFh0KWro7vLXZQxxX/crirF0tDGH5nypffJzpmhCB4 fOPMFdDQI4kd36wLXOqHSpEruIP+kp9Bb97uDJY/RnL/BcJOE22Pz6jTQyeFajkwYsR2mluP5VYjB ADV908qUQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jjI7C-0007OD-Qs; Thu, 11 Jun 2020 07:59:10 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jjI79-0007Nr-69 for linux-arm-kernel@lists.infradead.org; Thu, 11 Jun 2020 07:59:09 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A277B204EA; Thu, 11 Jun 2020 07:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591862346; bh=OosHKHNgy/JfsuiXlWm6kqNlEzxuPgPk1Y8ZZaJeWD0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xdnE9ijSYCm2ieKcA6MjTtuO04MHTQe1Et0EXVKYQCTKFPlQEVb9Yfj8kMl8AR13w Qa+QrSTirgnpvN11t74TOELy0TkE+PQGhIX4EOiSYHH4YRZ7TbRRaDjLYoA1zHsodf +Qk2xXT4keuJXovgH5hLfKz2s8TnNRSdO4NRUwV4= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjI77-0021Wl-9L; Thu, 11 Jun 2020 08:59:05 +0100 MIME-Version: 1.0 Date: Thu, 11 Jun 2020 08:59:05 +0100 From: Marc Zyngier To: Sean Christopherson Subject: Re: [PATCH 17/21] KVM: arm64: Use common code's approach for __GFP_ZERO with memory caches In-Reply-To: <20200605213853.14959-18-sean.j.christopherson@intel.com> References: <20200605213853.14959-1-sean.j.christopherson@intel.com> <20200605213853.14959-18-sean.j.christopherson@intel.com> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <6cc08074c289cbea7b9c1deeaf18c63f@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: sean.j.christopherson@intel.com, paulus@ozlabs.org, borntraeger@de.ibm.com, frankja@linux.ibm.com, pbonzini@redhat.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, david@redhat.com, cohuck@redhat.com, imbrenda@linux.ibm.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org, pfeiner@google.com, pshier@google.com, junaids@google.com, bgardon@google.com, christoffer.dall@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200611_005907_271227_03993EFE X-CRM114-Status: GOOD ( 17.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Christoffer Dall , Wanpeng Li , kvm@vger.kernel.org, David Hildenbrand , linux-kernel@vger.kernel.org, Paul Mackerras , Ben Gardon , Claudio Imbrenda , kvmarm@lists.cs.columbia.edu, Janosch Frank , Joerg Roedel , Christian Borntraeger , Julien Thierry , Junaid Shahid , Suzuki K Poulose , kvm-ppc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jim Mattson , Cornelia Huck , Peter Shier , linux-mips@vger.kernel.org, James Morse , Paolo Bonzini , Vitaly Kuznetsov , Peter Feiner Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Sean, On 2020-06-05 22:38, Sean Christopherson wrote: > Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to > make > the struct and its usage compatible with the common 'struct > kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code > churn when arm64 moves to the common implementation in a future patch, > at > the cost of temporarily having somewhat silly code. > > No functional change intended. > > Signed-off-by: Sean Christopherson > --- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/arm.c | 2 ++ > arch/arm64/kvm/mmu.c | 5 +++-- > 3 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h > b/arch/arm64/include/asm/kvm_host.h > index abbdf9703e20..2385dede96e0 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -105,6 +105,7 @@ struct kvm_arch { > */ > struct kvm_mmu_memory_cache { > int nobjs; > + gfp_t gfp_zero; > void *objects[KVM_NR_MEM_OBJS]; > }; > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 45276ed50dd6..4c98c6b4d850 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -270,6 +270,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) > vcpu->arch.target = -1; > bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES); > > + vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO; > + > /* Set up the timer */ > kvm_timer_vcpu_init(vcpu); > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index 9398b66f8a87..688213ef34f0 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -131,7 +131,8 @@ static int mmu_topup_memory_cache(struct > kvm_mmu_memory_cache *cache, int min) > if (cache->nobjs >= min) > return 0; > while (cache->nobjs < ARRAY_SIZE(cache->objects)) { > - page = (void *)__get_free_page(GFP_PGTABLE_USER); > + page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT | This is definitely a change in the way we account for guest page tables allocation, although I find it bizarre that not all architectures account for it the same way. It seems logical to me that nested page tables would be accounted against userspace, but I'm willing to be educated on the matter. Another possibility is that depending on the context, some allocations should be accounted on either the kernel or userspace (NV on arm64 could definitely do something like that). If that was the case, maybe moving most of the GFP_* flags into the per-cache flags, and have the renaming that Ben suggested earlier. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel