Re: [PATCH v4 07/17] KVM: arm64: Add PKVM_HYP_REQ_HYP_ALLOC request

On Fri, 31 Jul 2026 at 16:08, <[email protected]> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The __pkvm_hyp_topup hypercall is incorrectly placed in the always-on band, making it reachable in standard nVHE mode.
> --
>
> --- Patch [7]: [PATCH v4 07/17] KVM: arm64: Add PKVM_HYP_REQ_HYP_ALLOC request ---
> commit c7805b75faa5ebe4c309f41eb0346f2ae0a468dd
> Author: Vincent Donnefort <[email protected]>
>
> KVM: arm64: Add PKVM_HYP_REQ_HYP_ALLOC request
>
> Introduce a new pkvm_hyp_request type asking the host to top up the pKVM
> heap allocator.
>
> > diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> > index 043495f7fc78b..b77acfd7d1c8a 100644
> > --- a/arch/arm64/include/asm/kvm_asm.h
> > +++ b/arch/arm64/include/asm/kvm_asm.h
> > @@ -89,6 +89,7 @@ enum __kvm_host_smccc_func {
> >       __KVM_HOST_SMCCC_FUNC___vgic_v3_restore_vmcr_aprs,
> >       __KVM_HOST_SMCCC_FUNC___vgic_v5_save_apr,
> >       __KVM_HOST_SMCCC_FUNC___vgic_v5_restore_vmcr_apr,
> > +     __KVM_HOST_SMCCC_FUNC___pkvm_hyp_topup,
> >
> >       MARKER(__KVM_HOST_SMCCC_FUNC_PKVM_ONLY),
>
> [Severity: Medium]
> Should __KVM_HOST_SMCCC_FUNC___pkvm_hyp_topup be placed after the
> __KVM_HOST_SMCCC_FUNC_PKVM_ONLY marker instead of before it?
>
> Placing it here in the always-on band makes it reachable in standard
> nVHE mode or before pKVM is finalized. If the host kernel executes this
> hypercall during those phases, it could attempt to invoke
> hyp_alloc_topup() against uninitialized pKVM heap structures, potentially
> causing a hypervisor panic.

It does not panic. __host_check_page_state_range() calls
check_range_allowed_memory() before it touches the vmemmap, and that
returns -EPERM because hyp_memblock_nr is zero outside protected mode.

No, it should not move. __pkvm_hyp_topup is in the always-on band
deliberately, so the host can top the heap up before deprivilege.

/fuad

>
> [ ... ]
>
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index d3c69de698f48..439b91fc8aecf 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> [ ... ]
> > @@ -740,6 +765,7 @@ static const hcall_t host_hcall[] = {
> >       HANDLE_FUNC(__vgic_v3_restore_vmcr_aprs),
> >       HANDLE_FUNC(__vgic_v5_save_apr),
> >       HANDLE_FUNC(__vgic_v5_restore_vmcr_apr),
> > +     HANDLE_FUNC(__pkvm_hyp_topup),
> >
> >       HANDLE_FUNC(__pkvm_host_share_hyp),
> >       HANDLE_FUNC(__pkvm_host_unshare_hyp),
>
> [Severity: Medium]
> Does this handler registration also need to be moved to mirror the
> enum placement in the finalized-only band?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7
>