[PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Bradley Morgan]

Protected guest faults charge long term pins to the VM's mm. Teardown
can run later from file release, where current->mm may be unrelated.

Drop the charge from kvm->mm instead.

Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
 arch/arm64/kvm/pkvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index 053e4f733e4b..428723b1b0f5 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
 		page = pfn_to_page(mapping->pfn);
 		WARN_ON_ONCE(mapping->nr_pages != 1);
 		unpin_user_pages_dirty_lock(&page, 1, true);
-		account_locked_vm(current->mm, 1, false);
+		account_locked_vm(kvm->mm, 1, false);
 		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
 		kfree(mapping);
 	}
-- 
2.53.0

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Marc Zyngier]

On Sun, 21 Jun 2026 22:31:55 +0100,
Bradley Morgan <include@grrlz.net> wrote:
> 
> Protected guest faults charge long term pins to the VM's mm. Teardown
> can run later from file release, where current->mm may be unrelated.
>
> Drop the charge from kvm->mm instead.
> 
> Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> Signed-off-by: Bradley Morgan <include@grrlz.net>
> ---
>  arch/arm64/kvm/pkvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 053e4f733e4b..428723b1b0f5 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
>  		page = pfn_to_page(mapping->pfn);
>  		WARN_ON_ONCE(mapping->nr_pages != 1);
>  		unpin_user_pages_dirty_lock(&page, 1, true);
> -		account_locked_vm(current->mm, 1, false);
> +		account_locked_vm(kvm->mm, 1, false);
>  		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
>  		kfree(mapping);
>  	}

Seems correct to me, as the final mmdrop(kvm->mm) occurs after S2
teardown.

Will, what do you think?

	M.

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

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Will Deacon]

On Mon, Jun 22, 2026 at 09:32:29AM +0100, Marc Zyngier wrote:
> On Sun, 21 Jun 2026 22:31:55 +0100,
> Bradley Morgan <include@grrlz.net> wrote:
> > 
> > Protected guest faults charge long term pins to the VM's mm. Teardown
> > can run later from file release, where current->mm may be unrelated.
> >
> > Drop the charge from kvm->mm instead.
> > 
> > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> > Signed-off-by: Bradley Morgan <include@grrlz.net>
> > ---
> >  arch/arm64/kvm/pkvm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> > index 053e4f733e4b..428723b1b0f5 100644
> > --- a/arch/arm64/kvm/pkvm.c
> > +++ b/arch/arm64/kvm/pkvm.c
> > @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
> >  		page = pfn_to_page(mapping->pfn);
> >  		WARN_ON_ONCE(mapping->nr_pages != 1);
> >  		unpin_user_pages_dirty_lock(&page, 1, true);
> > -		account_locked_vm(current->mm, 1, false);
> > +		account_locked_vm(kvm->mm, 1, false);
> >  		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> >  		kfree(mapping);
> >  	}
> 
> Seems correct to me, as the final mmdrop(kvm->mm) occurs after S2
> teardown.
> 
> Will, what do you think?

Thanks, this looks correct to me.

While I was thinking about it, I also started looking at the use of
'current->mm' in kvm_arch_prepare_memory_region() in case that should
also be 'kvm->mm'. However, I then realised that I don't really grok
that code at all because it does a bunch of checking on the VMAs with
mmap_read_lock(current->mm) held, but then that lock is dropped
immediately after doing the checks so I'm not really sure what they
are protected against. Presumably, the address space could be modified
as soon as the lock is dropped?

But it's hot, so I'm probably missing something here.

Will

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Marc Zyngier]

On Tue, 23 Jun 2026 14:41:20 +0100,
Will Deacon <will@kernel.org> wrote:
> 
> On Mon, Jun 22, 2026 at 09:32:29AM +0100, Marc Zyngier wrote:
> > On Sun, 21 Jun 2026 22:31:55 +0100,
> > Bradley Morgan <include@grrlz.net> wrote:
> > > 
> > > Protected guest faults charge long term pins to the VM's mm. Teardown
> > > can run later from file release, where current->mm may be unrelated.
> > >
> > > Drop the charge from kvm->mm instead.
> > > 
> > > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> > > Signed-off-by: Bradley Morgan <include@grrlz.net>
> > > ---
> > >  arch/arm64/kvm/pkvm.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> > > index 053e4f733e4b..428723b1b0f5 100644
> > > --- a/arch/arm64/kvm/pkvm.c
> > > +++ b/arch/arm64/kvm/pkvm.c
> > > @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
> > >  		page = pfn_to_page(mapping->pfn);
> > >  		WARN_ON_ONCE(mapping->nr_pages != 1);
> > >  		unpin_user_pages_dirty_lock(&page, 1, true);
> > > -		account_locked_vm(current->mm, 1, false);
> > > +		account_locked_vm(kvm->mm, 1, false);
> > >  		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> > >  		kfree(mapping);
> > >  	}
> > 
> > Seems correct to me, as the final mmdrop(kvm->mm) occurs after S2
> > teardown.
> > 
> > Will, what do you think?
> 
> Thanks, this looks correct to me.
> 
> While I was thinking about it, I also started looking at the use of
> 'current->mm' in kvm_arch_prepare_memory_region() in case that should
> also be 'kvm->mm'. However, I then realised that I don't really grok
> that code at all because it does a bunch of checking on the VMAs with
> mmap_read_lock(current->mm) held, but then that lock is dropped
> immediately after doing the checks so I'm not really sure what they
> are protected against. Presumably, the address space could be modified
> as soon as the lock is dropped?
> 
> But it's hot, so I'm probably missing something here.

I think this is just trying to catch a few obvious issues, such as
dirty logging on device memory, but that only works for well behaved
userspace that is making "a honest mistake".

For the more trying ones, we end-up doing the same checks again at
fault time anyway.

	M.


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

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Will Deacon]

On Tue, Jun 23, 2026 at 02:50:48PM +0100, Marc Zyngier wrote:
> On Tue, 23 Jun 2026 14:41:20 +0100,
> Will Deacon <will@kernel.org> wrote:
> > 
> > On Mon, Jun 22, 2026 at 09:32:29AM +0100, Marc Zyngier wrote:
> > > On Sun, 21 Jun 2026 22:31:55 +0100,
> > > Bradley Morgan <include@grrlz.net> wrote:
> > > > 
> > > > Protected guest faults charge long term pins to the VM's mm. Teardown
> > > > can run later from file release, where current->mm may be unrelated.
> > > >
> > > > Drop the charge from kvm->mm instead.
> > > > 
> > > > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> > > > Signed-off-by: Bradley Morgan <include@grrlz.net>
> > > > ---
> > > >  arch/arm64/kvm/pkvm.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> > > > index 053e4f733e4b..428723b1b0f5 100644
> > > > --- a/arch/arm64/kvm/pkvm.c
> > > > +++ b/arch/arm64/kvm/pkvm.c
> > > > @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
> > > >  		page = pfn_to_page(mapping->pfn);
> > > >  		WARN_ON_ONCE(mapping->nr_pages != 1);
> > > >  		unpin_user_pages_dirty_lock(&page, 1, true);
> > > > -		account_locked_vm(current->mm, 1, false);
> > > > +		account_locked_vm(kvm->mm, 1, false);
> > > >  		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> > > >  		kfree(mapping);
> > > >  	}
> > > 
> > > Seems correct to me, as the final mmdrop(kvm->mm) occurs after S2
> > > teardown.
> > > 
> > > Will, what do you think?
> > 
> > Thanks, this looks correct to me.
> > 
> > While I was thinking about it, I also started looking at the use of
> > 'current->mm' in kvm_arch_prepare_memory_region() in case that should
> > also be 'kvm->mm'. However, I then realised that I don't really grok
> > that code at all because it does a bunch of checking on the VMAs with
> > mmap_read_lock(current->mm) held, but then that lock is dropped
> > immediately after doing the checks so I'm not really sure what they
> > are protected against. Presumably, the address space could be modified
> > as soon as the lock is dropped?
> > 
> > But it's hot, so I'm probably missing something here.
> 
> I think this is just trying to catch a few obvious issues, such as
> dirty logging on device memory, but that only works for well behaved
> userspace that is making "a honest mistake".
> 
> For the more trying ones, we end-up doing the same checks again at
> fault time anyway.

Got it, so it's a best-effort check. Although it does mean that memslot
changes have to be done by the same mm as kvm->mm, otherwise you could
get a spurious error back from the kernel.

Will

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Fuad Tabba]

On Sun, 21 Jun 2026 at 22:32, Bradley Morgan <include@grrlz.net> wrote:
>
> Protected guest faults charge long term pins to the VM's mm. Teardown
> can run later from file release, where current->mm may be unrelated.
>
> Drop the charge from kvm->mm instead.
>
> Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> Signed-off-by: Bradley Morgan <include@grrlz.net>

Reproduced by creating a protected VM, running the vCPU to fault in a
page, then forking and having the child close the last fd reference.
Without the fix, the parent's VmLck leaks (the reclaim decrements the
child's mm, which is freed on exit). With the fix the parent's VmLck
returns to zero.

One minor observation: account_locked_vm() also passes `current` as
the task pointer to __account_locked_vm(), but on the decrement path
that is only used in the pr_debug log line, so it is technically wrong
but functionally harmless.

Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba < fuad.tabba@linux.dev>

Cheers,
/fuad

> ---
>  arch/arm64/kvm/pkvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 053e4f733e4b..428723b1b0f5 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
>                 page = pfn_to_page(mapping->pfn);
>                 WARN_ON_ONCE(mapping->nr_pages != 1);
>                 unpin_user_pages_dirty_lock(&page, 1, true);
> -               account_locked_vm(current->mm, 1, false);
> +               account_locked_vm(kvm->mm, 1, false);
>                 pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
>                 kfree(mapping);
>         }
> --
> 2.53.0
>

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Marc Zyngier]

On Mon, 22 Jun 2026 09:32:45 +0100,
Fuad Tabba <fuad.tabba@linux.dev> wrote:
> 
> On Sun, 21 Jun 2026 at 22:32, Bradley Morgan <include@grrlz.net> wrote:
> >
> > Protected guest faults charge long term pins to the VM's mm. Teardown
> > can run later from file release, where current->mm may be unrelated.
> >
> > Drop the charge from kvm->mm instead.
> >
> > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> > Signed-off-by: Bradley Morgan <include@grrlz.net>
> 
> Reproduced by creating a protected VM, running the vCPU to fault in a
> page, then forking and having the child close the last fd reference.
> Without the fix, the parent's VmLck leaks (the reclaim decrements the
> child's mm, which is freed on exit). With the fix the parent's VmLck
> returns to zero.
> 
> One minor observation: account_locked_vm() also passes `current` as
> the task pointer to __account_locked_vm(), but on the decrement path
> that is only used in the pr_debug log line, so it is technically wrong
> but functionally harmless.

I don't think this is wrong. Awkward, maybe. It is just that the
rlimit check and the accounting may be different contexts, and the
pr_debug() call covers both inc and dec.

>
> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
> Tested-by: Fuad Tabba < fuad.tabba@linux.dev>

Thanks,

	M.

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

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Bradley Morgan]

On June 22, 2026 10:16:18 AM GMT+01:00, Marc Zyngier <maz@kernel.org>
wrote:
>On Mon, 22 Jun 2026 09:32:45 +0100,
>Fuad Tabba <fuad.tabba@linux.dev> wrote:
>> 
>> On Sun, 21 Jun 2026 at 22:32, Bradley Morgan <include@grrlz.net> wrote:
>> >
>> > Protected guest faults charge long term pins to the VM's mm. Teardown
>> > can run later from file release, where current->mm may be unrelated.
>> >
>> > Drop the charge from kvm->mm instead.
>> >
>> > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to
>pkvm_pgtable_stage2_destroy()")
>> > Signed-off-by: Bradley Morgan <include@grrlz.net>
>> 
>> Reproduced by creating a protected VM, running the vCPU to fault in a
>> page, then forking and having the child close the last fd reference.
>> Without the fix, the parent's VmLck leaks (the reclaim decrements the
>> child's mm, which is freed on exit). With the fix the parent's VmLck
>> returns to zero.
>> 
>> One minor observation: account_locked_vm() also passes `current` as
>> the task pointer to __account_locked_vm(), but on the decrement path
>> that is only used in the pr_debug log line, so it is technically wrong
>> but functionally harmless.

I agree with marc here. Maybe awkward.


I tested it on my pixel 7! :)

>I don't think this is wrong. Awkward, maybe. It is just that the
>rlimit check and the accounting may be different contexts, and the
>pr_debug() call covers both inc and dec.
>
>>
>> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
>> Tested-by: Fuad Tabba < fuad.tabba@linux.dev>

Thanks for the review! :)

Cheers!

>Thanks,
>
>	M.
>
>

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Marc Zyngier]

On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
> Protected guest faults charge long term pins to the VM's mm. Teardown
> can run later from file release, where current->mm may be unrelated.
> 
> Drop the charge from kvm->mm instead.
> 
> 

Applied to fixes, thanks!

[1/1] KVM: arm64: account pKVM reclaim against the VM mm
      commit: d098bb75d14fde2f12155f1a95ec0168160867ce

Cheers,

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

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Bradley Morgan]

On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
>On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
>> Protected guest faults charge long term pins to the VM's mm. Teardown
>> can run later from file release, where current->mm may be unrelated.
>> 
>> Drop the charge from kvm->mm instead.
>> 
>> 
>
>Applied to fixes, thanks!
>
>[1/1] KVM: arm64: account pKVM reclaim against the VM mm
>      commit: d098bb75d14fde2f12155f1a95ec0168160867ce
>
>Cheers,
>
>	M.
>


Hey, which tree did you apply it to?


Thanks!

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Fuad Tabba]

On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
>
> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
> >> Protected guest faults charge long term pins to the VM's mm. Teardown
> >> can run later from file release, where current->mm may be unrelated.
> >>
> >> Drop the charge from kvm->mm instead.
> >>
> >>
> >
> >Applied to fixes, thanks!
> >
> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
> >      commit: d098bb75d14fde2f12155f1a95ec0168160867ce
> >
> >Cheers,
> >
> >       M.
> >
>
>
> Hey, which tree did you apply it to?

https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes

/fuad

>
>
> Thanks!

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Bradley Morgan]

On June 23, 2026 4:03:30 PM GMT+01:00, Fuad Tabba <fuad.tabba@linux.dev>
wrote:
>On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
>>
>> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org>
>wrote:
>> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
>> >> Protected guest faults charge long term pins to the VM's mm. Teardown
>> >> can run later from file release, where current->mm may be unrelated.
>> >>
>> >> Drop the charge from kvm->mm instead.
>> >>
>> >>
>> >
>> >Applied to fixes, thanks!
>> >
>> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
>> >      commit: d098bb75d14fde2f12155f1a95ec0168160867ce
>> >
>> >Cheers,
>> >
>> >       M.
>> >
>>
>>
>> Hey, which tree did you apply it to?
>
>https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes
>
>/fuad
>
>>
>>
>> Thanks!
>

Thanks fuad.

May I ask if this would be put onto ACK?

Since this affects pixel devices.

(E.g, my pixel 7....)

Thanks!

Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm

[Fuad Tabba]

Hi Bradley,

On Tue, 23 Jun 2026 at 16:11, Bradley Morgan <include@grrlz.net> wrote:
>
> On June 23, 2026 4:03:30 PM GMT+01:00, Fuad Tabba <fuad.tabba@linux.dev>
> wrote:
> >On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
> >>
> >> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org>
> >wrote:
> >> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
> >> >> Protected guest faults charge long term pins to the VM's mm. Teardown
> >> >> can run later from file release, where current->mm may be unrelated.
> >> >>
> >> >> Drop the charge from kvm->mm instead.
> >> >>
> >> >>
> >> >
> >> >Applied to fixes, thanks!
> >> >
> >> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
> >> >      commit: d098bb75d14fde2f12155f1a95ec0168160867ce
> >> >
> >> >Cheers,
> >> >
> >> >       M.
> >> >
> >>
> >>
> >> Hey, which tree did you apply it to?
> >
> >https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes
> >
> >/fuad
> >
> >>
> >>
> >> Thanks!
> >
>
> Thanks fuad.
>
> May I ask if this would be put onto ACK?

Yes, I'll pick it into ACK.

Cheers,
/fuad

>
> Since this affects pixel devices.
>
> (E.g, my pixel 7....)
>
> Thanks!