[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21d1f531-fe95-224d-0dac-6917d473063d@redhat.com>
Date: Wed, 17 Mar 2021 11:55:00 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Wanpeng Li <kernellwp@...il.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, Ben Gardon <bgardon@...gle.com>,
Shakeel Butt <shakeelb@...gle.com>
Subject: Re: [PATCH] KVM: arm: memcg awareness
On 17/03/21 11:53, Marc Zyngier wrote:
> On Wed, 17 Mar 2021 10:40:23 +0000,
> Paolo Bonzini <pbonzini@...hat.com> 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.
Paolo
Powered by blists - more mailing lists