diff options
| author | Quentin Perret <[email protected]> | 2021-03-19 10:01:20 +0000 |
|---|---|---|
| committer | Marc Zyngier <[email protected]> | 2021-03-19 12:01:20 +0000 |
| commit | 8e17c66249e9ea08b44879c7af0315e70a83316c (patch) | |
| tree | 24c1909adcf9746d61c4485bfc89eb704de6d633 /tools/perf/scripts/python | |
| parent | 40d9e41e525c13d07bc72d49968926f4502e5b33 (diff) | |
KVM: arm64: Introduce a Hyp buddy page allocator
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.
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Quentin Perret <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions