Re: [PATCH 1/1] KVM: arm64: Make kvm_s2_fault_pin_pfn() fault-in interruptible

[Marc Zyngier <maz@kernel.org>]

On Mon, 08 Jun 2026 11:43:36 +0100,
Jia He <justin.he@arm.com> wrote:
> 
> arm64 KVM faults guest memory into the host in kvm_s2_fault_pin_pfn() via
> __kvm_faultin_pfn(). Today this request is made non-interruptible, so if
> the host fault-in path blocks for a long time, a vCPU thread that already
> has a pending signal cannot leave the fault-in path until GUP eventually
> completes.
> 
> This is particularly painful during VM teardown, where userspace may
> signal vCPU threads while they are blocked faulting in guest memory. In
> that case there is no benefit in continuing to wait for the fault to
> complete; the vCPU should return to userspace and let the pending signal
> be handled.
> 
> Ask the generic KVM fault-in helper to use FOLL_INTERRUPTIBLE. When GUP
> reports a pending signal it returns KVM_PFN_ERR_SIGPENDING; handle it by
> calling kvm_handle_signal_exit() and returning -EINTR. This matches the
> behaviour expected by the generic KVM fault-in path and mirrors the
> signal-exit handling already done by the arm64 run loop, which sets
> run->exit_reason = KVM_EXIT_INTR before returning to userspace. It is
> also consistent with architectures such as x86 that already allow the
> fault-in to be interrupted by pending signals.

Only x86, AFAICT. s390 handles signals, but doesn't set GUP as
interruptible.

> 
> The interrupted fault does not install a partial stage-2 mapping: the
> -EINTR is returned before any mapping is created, so the fault is simply
> retried on a subsequent vCPU entry once userspace re-enters KVM_RUN. The
> only observable effect in the absence of a pending signal is none; this

This sentence reads bizarrely. Do you mean to say "there is no
observable effect in the absence of a pending signal"?

> does not make ordinary stage-2 faults abortable.
> 
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
>  arch/arm64/kvm/mmu.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 4da9281312eb..dfb779e6d792 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1872,19 +1872,27 @@ static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
>  				struct kvm_s2_fault_vma_info *s2vi)
>  {
>  	int ret;
> +	unsigned int flags = FOLL_INTERRUPTIBLE;
>  
>  	ret = kvm_s2_fault_get_vma_info(s2fd, s2vi);
>  	if (ret)
>  		return ret;
>  
> +	if (kvm_is_write_fault(s2fd->vcpu))
> +		flags |= FOLL_WRITE;
> +

nit: you might as well keep the assignment and the update together.

>  	s2vi->pfn = __kvm_faultin_pfn(s2fd->memslot, get_canonical_gfn(s2fd, s2vi),
> -				      kvm_is_write_fault(s2fd->vcpu) ? FOLL_WRITE : 0,
> +				      flags,
>  				      &s2vi->map_writable, &s2vi->page);
>  	if (unlikely(is_error_noslot_pfn(s2vi->pfn))) {
>  		if (s2vi->pfn == KVM_PFN_ERR_HWPOISON) {
>  			kvm_send_hwpoison_signal(s2fd->hva, __ffs(s2vi->vma_pagesize));
>  			return 0;
>  		}
> +		if (is_sigpending_pfn(s2vi->pfn)) {
> +			kvm_handle_signal_exit(s2fd->vcpu);
> +			return -EINTR;
> +		}
>  		return -EFAULT;
>  	}
>  

The VNCR handling code also uses __kvm_faultin_pfn(). Why isn't it
similarly updated, given that you are specifically singling out NV as
an area of concern?

Similarly. pkvm_mem_abort() is using FOLL* flags and could benefit
from the same optimisation.

Thanks,

	M.

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