[PATCH 08/20] KVM: arm64: Add a range to __pkvm_host_reclaim_page_guest()
Vincent Donnefort
vdonnefort at google.com
Tue Sep 8 03:22:49 PDT 2026
On Mon, Sep 07, 2026 at 03:52:34PM +0100, Wei-Lin Chang wrote:
> On Mon, Aug 03, 2026 at 11:08:52AM +0100, Vincent Donnefort wrote:
>
> [...]
>
> > +int __pkvm_host_reclaim_page_guest(u64 gfn, u64 nr_pages, struct pkvm_hyp_vm *vm);
> > int __pkvm_host_share_guest(u64 pfn, u64 gfn, u64 nr_pages, struct pkvm_hyp_vcpu *vcpu,
> > enum kvm_pgtable_prot prot);
> > int __pkvm_host_unshare_guest(u64 gfn, u64 nr_pages, struct pkvm_hyp_vm *hyp_vm);
> > diff --git a/arch/arm64/kvm/hyp/include/nvhe/pkvm.h b/arch/arm64/kvm/hyp/include/nvhe/pkvm.h
> > index f04cea5ff389..0d17e59d5335 100644
> > --- a/arch/arm64/kvm/hyp/include/nvhe/pkvm.h
> > +++ b/arch/arm64/kvm/hyp/include/nvhe/pkvm.h
> > @@ -74,7 +74,7 @@ int __pkvm_init_vm(struct kvm *host_kvm, unsigned long vm_hva,
> > int __pkvm_init_vcpu(pkvm_handle_t handle, struct kvm_vcpu *host_vcpu,
> > unsigned long vcpu_hva);
> >
> > -int __pkvm_reclaim_dying_guest_page(pkvm_handle_t handle, u64 gfn);
> > +int __pkvm_reclaim_dying_guest_page(pkvm_handle_t handle, u64 gfn, u64 nr_pages);
>
> I feel like __pkvm_host_reclaim_"page"_guest(),
> __pkvm_reclaim_dying_guest_"page"() aren't good names since they deal
> with multiple pages now.
We could argue that it is "huge" page, but then none of the other mem_protect
functions are using _page_ in their name.
>
> [...]
>
> >
> > -static int get_valid_guest_pte(struct pkvm_hyp_vm *vm, u64 ipa, kvm_pte_t *ptep, u64 *physp)
> > +static int __get_valid_guest_pte(struct pkvm_hyp_vm *vm, u64 ipa,
> > + kvm_pte_t *ptep, u64 *physp, s8 *levelp)
> > {
> > kvm_pte_t pte;
> > u64 phys;
> > @@ -905,20 +906,32 @@ static int get_valid_guest_pte(struct pkvm_hyp_vm *vm, u64 ipa, kvm_pte_t *ptep,
> > return -EHWPOISON;
> > if (!kvm_pte_valid(pte))
> > return -ENOENT;
> > - if (level != KVM_PGTABLE_LAST_LEVEL)
> > - return -E2BIG;
> >
> > phys = kvm_pte_to_phys(pte);
> > - ret = check_range_allowed_memory(phys, phys + PAGE_SIZE);
> > + ret = check_range_allowed_memory(phys, phys + kvm_granule_size(level));
> > if (WARN_ON(ret))
> > return ret;
> >
> > *ptep = pte;
> > *physp = phys;
> > + *levelp = level;
> >
> > return 0;
> > }
> >
> > +static int get_valid_guest_pte(struct pkvm_hyp_vm *vm, u64 ipa, u64 size,
> > + kvm_pte_t *ptep, u64 *physp)
> > +{
> > + s8 level;
> > + int ret;
> > +
> > + ret = __get_valid_guest_pte(vm, ipa, ptep, physp, &level);
> > + if (ret)
> > + return ret;
> > +
> > + return kvm_granule_size(level) == size ? 0 : -E2BIG;
> > +}
> > +
> > int __pkvm_vcpu_in_poison_fault(struct pkvm_hyp_vcpu *hyp_vcpu)
> > {
> > struct pkvm_hyp_vm *vm = pkvm_hyp_vcpu_to_hyp_vm(hyp_vcpu);
> > @@ -1001,7 +1014,7 @@ int __pkvm_guest_share_host(struct pkvm_hyp_vcpu *vcpu, u64 gfn)
> > host_lock_component();
> > guest_lock_component(vm);
> >
> > - ret = get_valid_guest_pte(vm, ipa, &pte, &phys);
> > + ret = get_valid_guest_pte(vm, ipa, PAGE_SIZE, &pte, &phys);
> > if (ret)
> > goto unlock;
> >
> > @@ -1033,7 +1046,7 @@ int __pkvm_guest_unshare_host(struct pkvm_hyp_vcpu *vcpu, u64 gfn)
> > host_lock_component();
> > guest_lock_component(vm);
> >
> > - ret = get_valid_guest_pte(vm, ipa, &pte, &phys);
> > + ret = get_valid_guest_pte(vm, ipa, PAGE_SIZE, &pte, &phys);
> > if (ret)
> > goto unlock;
> >
> > @@ -1285,6 +1298,14 @@ static void hyp_poison_page(phys_addr_t phys)
> > hyp_fixmap_unmap();
> > }
> >
> > +static void hyp_poison_range(phys_addr_t phys, u64 size)
> > +{
> > + u64 offset;
> > +
> > + for (offset = 0; offset < size; offset += PAGE_SIZE)
> > + hyp_poison_page(phys + offset);
> > +}
> > +
>
> I believe get_valid_guest_pte and hyp_poison_range changes/addition can
> be made into its own patch, focusing on small helpers?
> If so I believe it can make reviewing easier.
>
> Thanks,
> Wei-Lin Chang
>
> [...]
I am not a big fan of the "No functional change intended" changes, but it is
true that this commit is quite big. So if you believe this makes it easier to
review, then let's split it.
--
Vincent
More information about the linux-arm-kernel
mailing list