Re: [PATCH v3 19/23] KVM: arm64: Add __pkvm_host_split_guest HVC

[Vincent Donnefort <vdonnefort@google.com>]

On Mon, Nov 02, 2026 at 09:13:51PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] KVM: arm64: Missing host_stage2_try() when splitting host stage-2 GFN metadata
> --
> 
> commit 1780446e119343d8ac04e9e17e8d107c87019c8d
> Author: Vincent Donnefort <vdonnefort@google.com>
> 
> KVM: arm64: Add __pkvm_host_split_guest HVC
> 
> This commit introduces the __pkvm_host_split_guest hypercall so the host can
> split a PMD block mapping in a protected VM's stage-2 page table and update
> the corresponding host stage-2 GFN metadata annotations to page granularity.
> 
> > diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> > index 88af0aec1ea92..7ecf4c98d7b5e 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> 
> [ ... ]
> 
> > @@ -690,17 +693,59 @@ static int host_stage2_decode_gfn_meta(kvm_pte_t pte, struct pkvm_hyp_vm **vm,
> >  		return -EPERM;
> >  
> >  	meta = FIELD_GET(KVM_HOST_DONATION_PTE_EXTRA_MASK, pte);
> > -	handle = FIELD_GET(KVM_HOST_PTE_OWNER_GUEST_HANDLE_MASK, meta);
> > -	*vm = get_vm_by_handle(handle);
> > -	if (!*vm) {
> > -		/* We probably raced with teardown; try again */
> > -		return -EAGAIN;
> > -	}
> > -
> > +	*handle = FIELD_GET(KVM_HOST_PTE_OWNER_GUEST_HANDLE_MASK, meta);
> >  	*gfn = FIELD_GET(KVM_HOST_PTE_OWNER_GUEST_GFN_MASK, meta);
> >  	return 0;
> >  }
> >  
> > +static int host_stage2_split_gfn_meta(phys_addr_t phys, u64 ipa, u64 size, struct pkvm_hyp_vm *vm)
> > +{
> > +	struct kvm_pgtable_mm_ops *mm_ops = &host_mmu.mm_ops;
> > +	struct kvm_pgtable *pgt = &host_mmu.pgt;
> > +	kvm_pte_t pte, *table, *ptep;
> > +	pkvm_handle_t handle;
> > +	s8 level;
> > +	u64 gfn;
> > +	int ret;
> > +
> > +	ret = kvm_pgtable_get_leaf(pgt, phys, &pte, &level, 0);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (kvm_granule_size(level) != size)
> > +		return -EINVAL;
> > +
> > +	ret = host_stage2_decode_gfn_meta(pte, &handle, &gfn);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (handle != vm->kvm.arch.pkvm.handle || gfn != (ipa >> PAGE_SHIFT))
> > +		return -EINVAL;
> > +
> > +	table = mm_ops->zalloc_page(&host_s2_pool);
> > +	if (!table)
> > +		return -ENOMEM;
> 
> [ ... ]
> 
> > @@ -1778,6 +1830,55 @@ int __pkvm_host_mkyoung_guest(u64 gfn, struct pkvm_hyp_vcpu *vcpu)
> >  	return 0;
> >  }
> >  
> > +int __pkvm_host_split_guest(u64 gfn, u64 nr_pages, struct pkvm_hyp_vcpu *vcpu)
> > +{
> > +	struct kvm_hyp_memcache *mc = &vcpu->vcpu.arch.stage2_mc;
> > +	struct pkvm_hyp_vm *vm = pkvm_hyp_vcpu_to_hyp_vm(vcpu);
> > +	u64 size = nr_pages << PAGE_SHIFT;
> > +	u64 ipa = hyp_pfn_to_phys(gfn);
> > +	kvm_pte_t pte, *table;
> > +	phys_addr_t phys;
> > +	s8 level;
> > +	int ret;
> > +
> > +	if (!mc->nr_pages)
> > +		return -ENOMEM;
> > +
> > +	if (size != PMD_SIZE || !IS_ALIGNED(ipa, PMD_SIZE))
> > +		return -EINVAL;
> > +
> > +	level = KVM_PGTABLE_LAST_LEVEL - 1;
> > +
> > +	host_lock_component();
> > +	guest_lock_component(vm);
> > +
> > +	ret = get_valid_guest_pte(vm, ipa, size, &pte, &phys);
> > +	if (ret)
> > +		goto unlock;
> > +
> > +	table = kvm_pgtable_stage2_create_unlinked(&vm->pgt, kvm_pte_to_phys(pte), level,
> > +						   kvm_pgtable_stage2_pte_prot(pte),
> > +						   mc, true);
> > +	if (IS_ERR(table)) {
> > +		ret = PTR_ERR(table);
> > +		goto unlock;
> > +	}
> > +
> > +	ret = host_stage2_split_gfn_meta(phys, ipa, size, vm);
> 
> [Severity: Medium]
> Should the call to host_stage2_split_gfn_meta() be wrapped with
> host_stage2_try()?
> 
> In host_stage2_split_gfn_meta(), mm_ops->zalloc_page(&host_s2_pool)
> allocates a page-table page from the fixed-size host_s2_pool. When system
> RAM is mapped or donated at PMD block granularity in host_mmu.pgt, the
> unused PTE-level page-table pages in host_s2_pool can be consumed by host
> MMIO mappings faulted in via handle_host_mem_abort() -> host_stage2_idmap().
> 
> Other callers that allocate from host_s2_pool (such as
> host_stage2_idmap_locked() and host_stage2_set_owner_metadata_locked()) wrap
> their page-table operations in host_stage2_try(), which handles -ENOMEM by
> calling host_stage2_unmap_dev_all() to reclaim MMIO page-table pages and
> retrying.
> 
> Because pkvm_refill_memcache() only refills the guest stage2_mc, can
> __pkvm_host_split_guest() fail with -ENOMEM if host MMIO mappings have
> exhausted host_s2_pool?
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261102204628.401871-1-vdonnefort@google.com?part=19

The size of the host stage-2 pool makes it very much unlikely the retry will
ever be hit. 

But better to align with the other callers.

-- 
Vincent