[PATCH v2 18/18] KVM: arm64: Alloc simple_buffer_page using pKVM hyp allocator

[Vincent Donnefort]

On Mon, Jul 20, 2026 at 03:04:03PM +0100, Vincent Donnefort wrote:
> On Wed, Jul 15, 2026 at 04:07:05PM +0100, Fuad Tabba wrote:
> > On Mon, 6 Jul 2026 at 18:54, Vincent Donnefort <vdonnefort at google.com> wrote:
> > 
> > ...
> > 
> > > @@ -193,17 +211,8 @@ static bool hyp_trace_desc_is_valid(struct hyp_trace_desc *desc, size_t desc_siz
> > >                 if ((void *)rb_desc + struct_size(rb_desc, page_va, rb_desc->nr_page_va) > desc_end)
> > >                         return false;
> > >
> > > -               /* Overflow bpages backing memory? */
> > > -               if (nr_bpages < rb_desc->nr_page_va)
> > > -                       return false;
> > > -
> > > -               if (cpu >= hyp_nr_cpus)
> > > -                       return false;
> > > -
> > >                 if (cpu != rb_desc->cpu)
> > >                         return false;
> > 
> > Sashiko flagged this. Nothing here bounds nr_page_va from below, so
> > with nr_page_va == 0 on every CPU the bpage size sums to 0.
> > hyp_alloc() still hands back a chunk, but bpages_backing_size is
> > stored as 0, so when init_mm() fails on nr_page_va < 3 the free path
> > takes its if (!size) return and never frees it. The host can repeat
> > it. Would validating nr_page_va >= 3 here work?
> 
> simple_ring_buffer_init_mm() already validates nr_page_va. And on error, we do
> seem to rollback properly and hyp_free().
> 
> So I don't believe there's anything to do here.

Ahhh no my bad! Sashiko's right. Because the size is 0... this will appear as
"unloaded" ...

Indeed perhaps the best check here is to make sure we have the minium
nr_page_va...

> 
> > 
> > I don't think the rest of Sashiko's note holds: the zero-size path
> > succeeds rather than hitting -ENOMEM. And it's only reachable from the
> > host kernel, not userspace.
> > 
> > Cheers,
> > /fuad