[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210311161441.GC31206@willie-the-truck>
Date: Thu, 11 Mar 2021 16:14:42 +0000
From: Will Deacon <will@...nel.org>
To: Quentin Perret <qperret@...gle.com>
Cc: catalin.marinas@....com, maz@...nel.org, james.morse@....com,
julien.thierry.kdev@...il.com, suzuki.poulose@....com,
android-kvm@...gle.com, linux-kernel@...r.kernel.org,
kernel-team@...roid.com, kvmarm@...ts.cs.columbia.edu,
linux-arm-kernel@...ts.infradead.org, tabba@...gle.com,
mark.rutland@....com, dbrazdil@...gle.com, mate.toth-pal@....com,
seanjc@...gle.com, robh+dt@...nel.org, ardb@...nel.org
Subject: Re: [PATCH v4 12/34] KVM: arm64: Introduce a Hyp buddy page allocator
On Wed, Mar 10, 2021 at 05:57:29PM +0000, Quentin Perret wrote:
> When memory protection is enabled, the hyp code will require a basic
> form of memory management in order to allocate and free memory pages at
> EL2. This is needed for various use-cases, including the creation of hyp
> mappings or the allocation of stage 2 page tables.
>
> To address these use-case, introduce a simple memory allocator in the
> hyp code. The allocator is designed as a conventional 'buddy allocator',
> working with a page granularity. It allows to allocate and free
> physically contiguous pages from memory 'pools', with a guaranteed order
> alignment in the PA space. Each page in a memory pool is associated
> with a struct hyp_page which holds the page's metadata, including its
> refcount, as well as its current order, hence mimicking the kernel's
> buddy system in the GFP infrastructure. The hyp_page metadata are made
> accessible through a hyp_vmemmap, following the concept of
> SPARSE_VMEMMAP in the kernel.
>
> Signed-off-by: Quentin Perret <qperret@...gle.com>
> ---
> arch/arm64/kvm/hyp/include/nvhe/gfp.h | 68 ++++++++
> arch/arm64/kvm/hyp/include/nvhe/memory.h | 28 ++++
> arch/arm64/kvm/hyp/nvhe/Makefile | 2 +-
> arch/arm64/kvm/hyp/nvhe/page_alloc.c | 195 +++++++++++++++++++++++
> 4 files changed, 292 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/kvm/hyp/include/nvhe/gfp.h
> create mode 100644 arch/arm64/kvm/hyp/nvhe/page_alloc.c
Eventually, we can replace the refcount with refcount_t, but for now this
looks pretty good:
Acked-by: Will Deacon <will@...nel.org>
Will
Powered by blists - more mailing lists