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=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,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 D9849C433DB for ; Wed, 17 Mar 2021 11:04:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 93FF264F64 for ; Wed, 17 Mar 2021 11:04:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231308AbhCQLDr (ORCPT ); Wed, 17 Mar 2021 07:03:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:45528 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231301AbhCQLDR (ORCPT ); Wed, 17 Mar 2021 07:03:17 -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 027CD64F64; Wed, 17 Mar 2021 11:03:17 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lMTxK-002C2j-TG; Wed, 17 Mar 2021 11:03:15 +0000 Date: Wed, 17 Mar 2021 11:03:14 +0000 Message-ID: <87h7lahwjx.wl-maz@kernel.org> From: Marc Zyngier To: Paolo Bonzini Cc: Wanpeng Li , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Ben Gardon , Shakeel Butt Subject: Re: [PATCH] KVM: arm: memcg awareness In-Reply-To: <21d1f531-fe95-224d-0dac-6917d473063d@redhat.com> References: <1615959984-7122-1-git-send-email-wanpengli@tencent.com> <87mtv2i1s3.wl-maz@kernel.org> <87im5qhwzx.wl-maz@kernel.org> <21d1f531-fe95-224d-0dac-6917d473063d@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: pbonzini@redhat.com, kernellwp@gmail.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, bgardon@google.com, shakeelb@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 17 Mar 2021 10:55:00 +0000, Paolo Bonzini wrote: > > On 17/03/21 11:53, Marc Zyngier wrote: > > On Wed, 17 Mar 2021 10:40:23 +0000, > > Paolo Bonzini wrote: > >> > >> On 17/03/21 10:10, Marc Zyngier wrote: > >>>> @@ -366,7 +366,7 @@ static int hyp_map_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep, > >>>> if (WARN_ON(level == KVM_PGTABLE_MAX_LEVELS - 1)) > >>>> return -EINVAL; > >>>> - childp = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL); > >>>> + childp = (kvm_pte_t *)get_zeroed_page(GFP_KERNEL_ACCOUNT); > >>> No, this is wrong. > >>> > >>> You cannot account the hypervisor page tables to the guest because we > >>> don't ever unmap them, and that we can't distinguish two data > >>> structures from two different VMs occupying the same page. > >> > >> If you never unmap them, there should at least be a shrinker to get > >> rid of unused pages in the event of memory pressure. > > > > We don't track where these pages are coming from or whether they can > > safely be unmapped. Until we can track such ownership and deal with > > page sharing, these mappings have to stay, > > > > At most, this represent the amount of memory required to map the whole > > of the linear mapping. > > Ah, these are the EL2 pages, not the stage2 page tables, right? If > so, sorry for the noise. Yes, EL2 page tables when running non-VHE. VHE doesn't have that problem for obvious reasons. Stage-2 page tables can be completely discarded at any point, and the MMU notifiers already deal with that. M. -- Without deviation from the norm, progress is not possible.