Re: [PATCH v2 03/18] KVM: arm64: Add __hyp_allocator_map for the pKVM hyp

[Vincent Donnefort <vdonnefort@google.com>]

On Tue, Jul 14, 2026 at 06:53:55PM +0100, Fuad Tabba wrote:
> On Mon, 6 Jul 2026 at 18:54, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > In preparation for the pKVM heap allocator, introduce __hyp_allocator_map()
> > to map a single physical page to a given virtual address in the hypervisor
> > stage-1 page-table.
> >
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> >
> > diff --git a/arch/arm64/kvm/hyp/include/nvhe/mm.h b/arch/arm64/kvm/hyp/include/nvhe/mm.h
> > index 725bb0fb941d..98a7774b541c 100644
> > --- a/arch/arm64/kvm/hyp/include/nvhe/mm.h
> > +++ b/arch/arm64/kvm/hyp/include/nvhe/mm.h
> > @@ -32,5 +32,6 @@ int __pkvm_create_private_mapping(phys_addr_t phys, size_t size,
> >  int pkvm_create_stack(phys_addr_t phys, unsigned long *haddr);
> >  int pkvm_alloc_private_va_range(size_t size, unsigned long *haddr);
> >  phys_addr_t __pkvm_private_range_pa(void *va);
> > +int __hyp_allocator_map(void *va, phys_addr_t phys);
> >
> >  #endif /* __KVM_HYP_MM_H */
> > diff --git a/arch/arm64/kvm/hyp/nvhe/mm.c b/arch/arm64/kvm/hyp/nvhe/mm.c
> > index ec59da1322a7..c1c01f81ac5f 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/mm.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/mm.c
> > @@ -160,6 +160,11 @@ void pkvm_remove_mappings(void *from, void *to)
> >         hyp_spin_unlock(&pkvm_pgd_lock);
> >  }
> >
> > +int __hyp_allocator_map(void *va, phys_addr_t phys)
> > +{
> > +       return __pkvm_create_mappings((unsigned long)va, PAGE_SIZE, phys, PAGE_HYP);
> > +}
> > +
> 
> nit: __hyp_allocator_map() is named for its caller rather than what it does
> (map a single hyp page). Its siblings here (pkvm_create_mappings,
> pkvm_remove_mappings) are named for the operation. Consider a name like
> pkvm_map_page() so it reads as a generic primitive.

IIRC (it was a few years ago) this was a suggestion from Quentin who didn't want
to expose too much of mm and suggested to make it clear that was a function
private to the allocator.

But looking at what we have now. perhaps 

int __pkvm_map_private_pages(phys_addr_t phys, void *addr, size_t size);

And this could verify that addr is actually aprt of the private range

WDYS?

> 
> That said, naming is hard:
> 
> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
> 
> Cheers,
> /fuad
> 
> >  int hyp_back_vmemmap(phys_addr_t back)
> >  {
> >         unsigned long i, start, size, end = 0;
> > --
> > 2.55.0.rc2.803.g1fd1e6609c-goog
> >