[PATCH v3 13/17] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator

Fuad Tabba tabba at google.com
Thu Jul 23 09:10:13 PDT 2026


On Thu, 23 Jul 2026 at 16:09, Vincent Donnefort <vdonnefort at google.com> wrote:
>
> On Thu, Jul 23, 2026 at 01:14:10PM +0100, Fuad Tabba wrote:
> > Hi Vincent,
> >
> > On Mon, 20 Jul 2026 at 18:15, Vincent Donnefort <vdonnefort at google.com> wrote:
> > ...
> >
> > > +static void errno_to_smccc(int ret, struct kvm_cpu_context *host_ctxt)
> > > +{
> > > +       struct pkvm_hyp_req req = { .type = PKVM_HYP_NO_REQ };
> > > +
> > > +       switch (ret) {
> > > +       case -ENOMEM:
> > > +               req.type = PKVM_HYP_REQ_HYP_ALLOC;
> > > +               req.mem.nr_pages = hyp_alloc_topup_needed();
> > > +               break;
> > > +       }
> >
> > Sashiko raised this in a different patch. This turns any -ENOMEM into
> > a top-up request, but hyp_allocator_map() also returns -ENOMEM from
> > the pkvm_map_private_va_range() failure path without setting
> > topup_needed, so nr_pages can be 0. The host then handles a 0-page
> > top-up and the while (!__ret) loop in pkvm_call_hyp_req() just
> > re-issues the same failing hypercall.
> >
> > This might not be reachable today, but could you make it so that
> > errno_to_smccc() raises the request only when nr_pages is non-zero,
> > and let -ENOMEM propagate otherwise?
>
> I could also introduce a HYP_ALLOC specific ENOMEM?
>
> Otherwise, yes checking on hyp_alloc_topup_needed() sounds alright.

No strong opinion, but it seems to me that checking on
hyp_alloc_topup_needed() is simpler and safer. That said, if you have
reason to do it differently I don't mind.

/fuad

>
> >
> > Cheers,
> > /fuad



More information about the linux-arm-kernel mailing list