Re: [PATCH v3 2/3] KVM: arm64: Distinct pKVM teardown memcache for stage-2

[Marc Zyngier]

On Thu, 13 Mar 2025 09:13:45 +0000,
Vincent Donnefort <vdonnefort@xxxxxxxxxx> wrote:
> 
> On Wed, Mar 12, 2025 at 08:59:15AM +0000, Marc Zyngier wrote:
> > On Fri, 07 Mar 2025 11:34:10 +0000,
> > Vincent Donnefort <vdonnefort@xxxxxxxxxx> wrote:
> > > 
> > > In order to account for memory dedicated to the stage-2 page-tables, use
> > > a separated memcache when tearing down the VM.
> > > 
> > > Signed-off-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
> > > 
> > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > > index 12691ae23d4c..ace3969e8106 100644
> > > --- a/arch/arm64/include/asm/kvm_host.h
> > > +++ b/arch/arm64/include/asm/kvm_host.h
> > > @@ -246,6 +246,7 @@ typedef unsigned int pkvm_handle_t;
> > >  struct kvm_protected_vm {
> > >  	pkvm_handle_t handle;
> > >  	struct kvm_hyp_memcache teardown_mc;
> > > +	struct kvm_hyp_memcache stage2_teardown_mc;
> > >  	bool enabled;
> > >  };
> > >  
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > index 3927fe52a3dd..15f8d5315959 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > @@ -678,7 +678,7 @@ teardown_donated_memory(struct kvm_hyp_memcache *mc, void *addr, size_t size)
> > >  
> > >  int __pkvm_teardown_vm(pkvm_handle_t handle)
> > >  {
> > > -	struct kvm_hyp_memcache *mc;
> > > +	struct kvm_hyp_memcache *mc, *stage2_mc;
> > >  	struct pkvm_hyp_vm *hyp_vm;
> > >  	struct kvm *host_kvm;
> > >  	unsigned int idx;
> > > @@ -706,7 +706,8 @@ int __pkvm_teardown_vm(pkvm_handle_t handle)
> > >  
> > >  	/* Reclaim guest pages (including page-table pages) */
> > >  	mc = &host_kvm->arch.pkvm.teardown_mc;
> > > -	reclaim_guest_pages(hyp_vm, mc);
> > > +	stage2_mc = &host_kvm->arch.pkvm.stage2_teardown_mc;
> > > +	reclaim_guest_pages(hyp_vm, stage2_mc);
> > 
> > This looks odd. What counts as stage-2 pages here? Or is it that
> > reclaim_guest_pages() is very badly named?
> 
> Yes, this is a naming issue here. How about 
> 
>   reclaim_pgtable_pages(hyp_vm, stage2_mc);

LGTM.

> 
> Then I can probably drop that /* Push the metadata pages to the teardown
> memcache */  comment as it is clear what is pgtable and what is meta-data?

Yeah, the comments are actively getting in the way.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.