From: Jia He <justin.he@arm.com>
To: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>
Cc: Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, Jia He <justin.he@arm.com>
Subject: [PATCH 1/1] KVM: arm64: Make kvm_s2_fault_pin_pfn() fault-in interruptible
Date: Mon, 8 Jun 2026 10:43:36 +0000 [thread overview]
Message-ID: <20260608104336.2405384-2-justin.he@arm.com> (raw)
In-Reply-To: <20260608104336.2405384-1-justin.he@arm.com>
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.
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
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;
+
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;
}
--
2.34.1
next prev parent reply other threads:[~2026-06-08 10:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 10:43 [PATCH 0/1] " Jia He
2026-06-08 10:43 ` Jia He [this message]
2026-06-08 15:28 ` [PATCH 1/1] " Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260608104336.2405384-2-justin.he@arm.com \
--to=justin.he@arm.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®