Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1395205ybg; Thu, 11 Jun 2020 08:46:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxiE7cN51hTDEDZh47FTGmV9ln+W9wzSJu6Nc8zJ3O4b32NM0V9JVLCoJwXXdK2hexHu/l2 X-Received: by 2002:a05:6402:690:: with SMTP id f16mr7781613edy.9.1591890380001; Thu, 11 Jun 2020 08:46:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591890379; cv=none; d=google.com; s=arc-20160816; b=Mt1Lj5q0KLG08pYt2yncy+6ujtE32lObnCZYaKMeD7pfHsvln8OJAaKpOXG17JKcaB Tt99NgAu3eUmdHCbCnFErX1tXcWBfd36Aps3zZfz+d8XEgn+0TNXaBEVC7bgeciTLgzn NT/j347Kkel9SZK4m4FnTfoe6hIQ1jj3J2wcfYjUK1pYT0IBR74BOXq1MVzyfhsFKxFH tDY0zKHxZYiRd0v9h/YXbuSM5KqvORdkpngQiDTwdTDg5gfKfdw8IeTolXPJdBPVNdEC Nx10ovpRSOCPLfyBH536dxG6jrDFwxlctC62GjM/y7Wfg+MgscOonYZMaNHg5pTOb4ef 4KOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=iDwMXYeH7NkP5QVrcnrsyKy7BNmYtEoEaSr+LwQ+l+w=; b=lwQ0IS5Weh5cC3yFpuZ9Ppe1DAk60DlKjQvMHpnUau+oeWMOnvMW8uuH8hyVtybBlk yxqJES0YuOVojL+AGEzmAJf6NbgoOvfG0EbEZGg7YEYZ+/sWF8xm5JoXB78G59Qq6cJ0 i15UQW6V59ogUwCrudjZVL9lUJlrSW4/Z49x5K6DJcrF4HY7GFLHQg4/DPIQ9JI4Y3+f 8Wfk6AzUCpCqmc2UWJzLMoLKX13xPZoSQ23r+X2eB4neowPdsWEvsEzmZN8Z01ylbrB4 S/hs8PMYZYgXxR9XrAh9vwW9+WGRPJQct949lxl+Jrwe8L3HP0i//93nlts32YUurelQ OUzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a21si1768150edr.375.2020.06.11.08.45.55; Thu, 11 Jun 2020 08:46:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728675AbgFKPoA (ORCPT + 99 others); Thu, 11 Jun 2020 11:44:00 -0400 Received: from mga03.intel.com ([134.134.136.65]:40538 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728496AbgFKPn7 (ORCPT ); Thu, 11 Jun 2020 11:43:59 -0400 IronPort-SDR: zVbYBjCm+9L7CvMejLIsQdTToMqnSAR/RHJ4NnfDXDmHKrJaHs392+3+drFf0F4Cv2P1+NSZnB los2p04MIFKQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2020 08:43:59 -0700 IronPort-SDR: +Ydw/4Fg05XSUVeVdaVnYwXl169Eie8ePVgfFpQAiQZ2NUmXKZaRvV2IeZsKgMR2pcPAaKpDpn +n8lSwG3SLOg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,499,1583222400"; d="scan'208";a="419144435" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by orsmga004.jf.intel.com with ESMTP; 11 Jun 2020 08:43:59 -0700 Date: Thu, 11 Jun 2020 08:43:59 -0700 From: Sean Christopherson To: Marc Zyngier 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 Message-ID: <20200611154359.GF29918@linux.intel.com> References: <20200605213853.14959-1-sean.j.christopherson@intel.com> <20200605213853.14959-18-sean.j.christopherson@intel.com> <6cc08074c289cbea7b9c1deeaf18c63f@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6cc08074c289cbea7b9c1deeaf18c63f@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 11, 2020 at 08:59:05AM +0100, Marc Zyngier wrote: > >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's not intended to be a functional change, i.e. the allocations should still be accounted: #define GFP_PGTABLE_USER (GFP_PGTABLE_KERNEL | __GFP_ACCOUNT) | -> #define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO) == GFP_KERNEL | __GFP_ACCOUNT | __GFP_ZERO versus #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT) with __GFP_ZERO explicitly OR'd in == GFP_KERNEL | __GFP_ACCOUNT | __GFP_ZERO I can put the above in the changelog, unless of course it's wrong and I've missed something. > 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...