[PATCH] KVM: PPC: Book3S HV: Disable preemption around host-side HPT lock users

[PATCH] KVM: PPC: Book3S HV: Disable preemption around host-side HPT lock users

[Amit Machhiwal]

A previous change ("KVM: PPC: Book3S HV: Add preempt_disable() around
virtual-mode HPTE bit-lock users") at [1] added preempt_disable() around
guest vCPU HPT hcalls and page fault handlers executed in virtual mode.
This ensures vCPU threads cannot be preempted while holding
HPTE_V_HVLOCK or the reverse-map lock.

However, several host-side virtual-mode paths in book3s_64_mmu_hv.c also
acquire HPTE_V_HVLOCK and lock_rmap() in process context with preemption
enabled.  Specifically, kvm_unmap_rmapp() and kvm_age_rmapp() take both
locks during MMU notifier callbacks and memslot flushes, while
resize_hpt_rehash_hpte() acquires HPTE_V_HVLOCK during HPT resizing.  If
a host thread is preempted while holding either bit-lock, any guest vCPU
thread scheduled on the same CPU spinning for the same lock with
preemption disabled will never yield, resulting in a permanent CPU hang.

Fix this by disabling preemption across these host-side critical
sections.

For kvm_unmap_rmapp() and kvm_age_rmapp(), place preempt_disable()
before lock_rmap() so that both the rmap chain lock and the subsequent
HPTE_V_HVLOCK bit-lock are held under a single non-preemptible window.
To preserve the ABBA lock ordering between the two locks, re-enable
preemption after dropping the rmap lock on any retry or early-exit path
before spinning on cpu_relax(), allowing the lock holder to be
scheduled.

For kvm_htab_write(), the HPT migration restore path, replace the direct
calls to kvmppc_do_h_remove() with kvmppc_virtmode_do_h_remove(), a thin
wrapper that brackets kvmppc_do_h_remove() with preempt_disable() and
preempt_enable(), mirroring the existing kvmppc_virtmode_do_h_enter()
helper.

For resize_hpt_rehash_hpte(), place preempt_disable() before the
try_lock_hpte() spin loop and preempt_enable() after unlock_hpte() at
the function exit.

[1] https://git.kernel.org/powerpc/c/abbbe5ff83e7c9ed3a4d61b73011f1df7bf87907

Fixes: 6165d5dd99db ("KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page faults")
Cc: stable@vger.kernel.org # v5.14+
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
---
Changes in this version:
- Separated host-side fixes in book3s_64_mmu_hv.c into a standalone patch
  (guest-side paths were merged from v1 resend).
- Previous discussion: https://lore.kernel.org/all/20261007182116.12479-3-amachhiw@linux.ibm.com/

 arch/powerpc/kvm/book3s_64_mmu_hv.c | 33 +++++++++++++++++++++++++++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 2ccb3d138f46..8d85ce3440ae 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -47,6 +47,9 @@
 static long kvmppc_virtmode_do_h_enter(struct kvm *kvm, unsigned long flags,
 				long pte_index, unsigned long pteh,
 				unsigned long ptel, unsigned long *pte_idx_ret);
+static void kvmppc_virtmode_do_h_remove(struct kvm *kvm, unsigned long flags,
+				unsigned long pte_index, unsigned long avpn,
+				unsigned long *hpret);
 
 struct kvm_resize_hpt {
 	/* These fields read-only after init */
@@ -308,6 +311,22 @@ static long kvmppc_virtmode_do_h_enter(struct kvm *kvm, unsigned long flags,
 
 }
 
+/*
+ * Virtual-mode H_REMOVE. kvmppc_do_h_remove() is also called from real mode,
+ * where preempt_disable() is not usable, so the guard stays here. The function
+ * spins on HPTE_V_HVLOCK and then lock_rmap() (via remove_revmap_chain());
+ * preemption must be disabled across both bit-locks so that spinning callers
+ * holding preempt_disable() can make forward progress.
+ */
+static void kvmppc_virtmode_do_h_remove(struct kvm *kvm, unsigned long flags,
+				unsigned long pte_index, unsigned long avpn,
+				unsigned long *hpret)
+{
+	preempt_disable();
+	kvmppc_do_h_remove(kvm, flags, pte_index, avpn, hpret);
+	preempt_enable();
+}
+
 static struct kvmppc_slb *kvmppc_mmu_book3s_hv_find_slbe(struct kvm_vcpu *vcpu,
 							 gva_t eaddr)
 {
@@ -810,9 +829,11 @@ static void kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 
 	rmapp = &memslot->arch.rmap[gfn - memslot->base_gfn];
 	for (;;) {
+		preempt_disable();
 		lock_rmap(rmapp);
 		if (!(*rmapp & KVMPPC_RMAP_PRESENT)) {
 			unlock_rmap(rmapp);
+			preempt_enable();
 			break;
 		}
 
@@ -826,6 +847,7 @@ static void kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 		if (!try_lock_hpte(hptep, HPTE_V_HVLOCK)) {
 			/* unlock rmap before spinning on the HPTE lock */
 			unlock_rmap(rmapp);
+			preempt_enable();
 			while (be64_to_cpu(hptep[0]) & HPTE_V_HVLOCK)
 				cpu_relax();
 			continue;
@@ -834,6 +856,7 @@ static void kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 		kvmppc_unmap_hpte(kvm, i, memslot, rmapp, gfn);
 		unlock_rmap(rmapp);
 		__unlock_hpte(hptep, be64_to_cpu(hptep[0]));
+		preempt_enable();
 	}
 }
 
@@ -890,6 +913,7 @@ static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 
 	rmapp = &memslot->arch.rmap[gfn - memslot->base_gfn];
  retry:
+	preempt_disable();
 	lock_rmap(rmapp);
 	if (*rmapp & KVMPPC_RMAP_REFERENCED) {
 		*rmapp &= ~KVMPPC_RMAP_REFERENCED;
@@ -897,6 +921,7 @@ static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 	}
 	if (!(*rmapp & KVMPPC_RMAP_PRESENT)) {
 		unlock_rmap(rmapp);
+		preempt_enable();
 		return ret;
 	}
 
@@ -912,6 +937,7 @@ static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 		if (!try_lock_hpte(hptep, HPTE_V_HVLOCK)) {
 			/* unlock rmap before spinning on the HPTE lock */
 			unlock_rmap(rmapp);
+			preempt_enable();
 			while (be64_to_cpu(hptep[0]) & HPTE_V_HVLOCK)
 				cpu_relax();
 			goto retry;
@@ -931,6 +957,7 @@ static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 	} while ((i = j) != head);
 
 	unlock_rmap(rmapp);
+	preempt_enable();
 	return ret;
 }
 
@@ -1219,6 +1246,7 @@ static unsigned long resize_hpt_rehash_hpte(struct kvm_resize_hpt *resize,
 	if (!(vpte & HPTE_V_VALID) && !(vpte & HPTE_V_ABSENT))
 		return 0; /* nothing to do */
 
+	preempt_disable();
 	while (!try_lock_hpte(hptep, HPTE_V_HVLOCK))
 		cpu_relax();
 
@@ -1346,6 +1374,7 @@ static unsigned long resize_hpt_rehash_hpte(struct kvm_resize_hpt *resize,
 
 out:
 	unlock_hpte(hptep, vpte);
+	preempt_enable();
 	return ret;
 }
 
@@ -1868,7 +1897,7 @@ static ssize_t kvm_htab_write(struct file *file, const char __user *buf,
 			nb += HPTE_SIZE;
 
 			if (be64_to_cpu(hptp[0]) & (HPTE_V_VALID | HPTE_V_ABSENT))
-				kvmppc_do_h_remove(kvm, 0, i, 0, tmp);
+				kvmppc_virtmode_do_h_remove(kvm, 0, i, 0, tmp);
 			err = -EIO;
 			ret = kvmppc_virtmode_do_h_enter(kvm, H_EXACT, i, v, r,
 							 tmp);
@@ -1897,7 +1926,7 @@ static ssize_t kvm_htab_write(struct file *file, const char __user *buf,
 
 		for (j = 0; j < hdr.n_invalid; ++j) {
 			if (be64_to_cpu(hptp[0]) & (HPTE_V_VALID | HPTE_V_ABSENT))
-				kvmppc_do_h_remove(kvm, 0, i, 0, tmp);
+				kvmppc_virtmode_do_h_remove(kvm, 0, i, 0, tmp);
 			++i;
 			hptp += 2;
 		}

base-commit: 129f5d395fd66b6587a5ac156b232cca060d6512
-- 
2.54.0 (Apple Git-157)

Re: [PATCH] KVM: PPC: Book3S HV: Disable preemption around host-side HPT lock users

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: missing preempt_disable() in kvm_test_age_rmapp() leading to deadlock
--

commit dbd9d3f82d3dd2c11f69c26045433b125bc70408
Author: Amit Machhiwal <amachhiw@linux.ibm.com>

KVM: PPC: Book3S HV: Disable preemption around host-side HPT lock users

This commit disables preemption around host-side virtual-mode paths that
acquire HPTE_V_HVLOCK and lock_rmap(). This prevents a permanent CPU hang
where a preempted host thread holding either bit-lock blocks a spinning
guest vCPU thread.

> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 2ccb3d138f46c..8d85ce3440ae3 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
[ ... ]
> @@ -890,6 +913,7 @@ static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
>  
>  	rmapp = &memslot->arch.rmap[gfn - memslot->base_gfn];
>   retry:
> +	preempt_disable();
>  	lock_rmap(rmapp);

[Severity: High]
Does this same deadlock risk apply to kvm_test_age_rmapp()?

Looking at kvm_test_age_rmapp() in the same file, it also acquires
the spinning rmap bit-lock without explicitly disabling preemption:

arch/powerpc/kvm/book3s_64_mmu_hv.c:kvm_test_age_rmapp() {
	...
	lock_rmap(rmapp);
	if (*rmapp & KVMPPC_RMAP_REFERENCED)
		goto out;
	...
}

kvm_test_age_rmapp() is invoked via MMU notifiers (like
mmu_notifier_test_young) holding the PTE lock. Under PREEMPT_RT, the PTE
lock is sleepable and does not disable preemption, so lock_rmap() is
acquired in a preemptible context.

If a host thread holding this bit-lock is preempted, and a guest vCPU
thread on the same CPU executes a virtual-mode path like
kvmppc_virtmode_do_h_remove() (which disables preemption) and attempts to
acquire the same rmap lock via remove_revmap_chain(), could it spin
indefinitely without yielding?

>  	if (*rmapp & KVMPPC_RMAP_REFERENCED) {
>  		*rmapp &= ~KVMPPC_RMAP_REFERENCED;
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014185215.71832-1-amachhiw@linux.ibm.com?part=1

Re: [PATCH] KVM: PPC: Book3S HV: Disable preemption around host-side HPT lock users

[Amit Machhiwal]

On 2026/10/14 07:09 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] kvm: missing preempt_disable() in kvm_test_age_rmapp() leading to deadlock
> --
> 
> commit dbd9d3f82d3dd2c11f69c26045433b125bc70408
> Author: Amit Machhiwal <amachhiw@linux.ibm.com>
> 
> KVM: PPC: Book3S HV: Disable preemption around host-side HPT lock users
> 
> This commit disables preemption around host-side virtual-mode paths that
> acquire HPTE_V_HVLOCK and lock_rmap(). This prevents a permanent CPU hang
> where a preempted host thread holding either bit-lock blocks a spinning
> guest vCPU thread.
> 
> > diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> > index 2ccb3d138f46c..8d85ce3440ae3 100644
> > --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> > +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> [ ... ]
> > @@ -890,6 +913,7 @@ static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
> >  
> >  	rmapp = &memslot->arch.rmap[gfn - memslot->base_gfn];
> >   retry:
> > +	preempt_disable();
> >  	lock_rmap(rmapp);
> 
> [Severity: High]
> Does this same deadlock risk apply to kvm_test_age_rmapp()?
> 
> Looking at kvm_test_age_rmapp() in the same file, it also acquires
> the spinning rmap bit-lock without explicitly disabling preemption:
> 
> arch/powerpc/kvm/book3s_64_mmu_hv.c:kvm_test_age_rmapp() {
> 	...
> 	lock_rmap(rmapp);
> 	if (*rmapp & KVMPPC_RMAP_REFERENCED)
> 		goto out;
> 	...
> }
> 
> kvm_test_age_rmapp() is invoked via MMU notifiers (like
> mmu_notifier_test_young) holding the PTE lock. Under PREEMPT_RT, the PTE
> lock is sleepable and does not disable preemption, so lock_rmap() is
> acquired in a preemptible context.
> 
> If a host thread holding this bit-lock is preempted, and a guest vCPU
> thread on the same CPU executes a virtual-mode path like
> kvmppc_virtmode_do_h_remove() (which disables preemption) and attempts to
> acquire the same rmap lock via remove_revmap_chain(), could it spin
> indefinitely without yielding?

No, this is not a problem on PPC.  I have explained the reason here:

  https://lore.kernel.org/all/20261008005700.c78e5a18-dc-amachhiw@linux.ibm.com

Thanks,
Amit

Re: [PATCH] KVM: PPC: Book3S HV: Disable preemption around host-side HPT lock users

[Ritesh Harjani]

Amit Machhiwal <amachhiw@linux.ibm.com> writes:

> A previous change ("KVM: PPC: Book3S HV: Add preempt_disable() around
> virtual-mode HPTE bit-lock users") at [1] added preempt_disable() around
> guest vCPU HPT hcalls and page fault handlers executed in virtual mode.
> This ensures vCPU threads cannot be preempted while holding
> HPTE_V_HVLOCK or the reverse-map lock.
>
> However, several host-side virtual-mode paths in book3s_64_mmu_hv.c also
> acquire HPTE_V_HVLOCK and lock_rmap() in process context with preemption
> enabled.  Specifically, kvm_unmap_rmapp() and kvm_age_rmapp() take both
> locks during MMU notifier callbacks and memslot flushes, while
> resize_hpt_rehash_hpte() acquires HPTE_V_HVLOCK during HPT resizing.  If
> a host thread is preempted while holding either bit-lock, any guest vCPU
> thread scheduled on the same CPU spinning for the same lock with
> preemption disabled will never yield, resulting in a permanent CPU hang.
>
> Fix this by disabling preemption across these host-side critical
> sections.
>
> For kvm_unmap_rmapp() and kvm_age_rmapp(), place preempt_disable()
> before lock_rmap() so that both the rmap chain lock and the subsequent
> HPTE_V_HVLOCK bit-lock are held under a single non-preemptible window.
> To preserve the ABBA lock ordering between the two locks, re-enable
> preemption after dropping the rmap lock on any retry or early-exit path
> before spinning on cpu_relax(), allowing the lock holder to be
> scheduled.
>
> For kvm_htab_write(), the HPT migration restore path, replace the direct
> calls to kvmppc_do_h_remove() with kvmppc_virtmode_do_h_remove(), a thin
> wrapper that brackets kvmppc_do_h_remove() with preempt_disable() and
> preempt_enable(), mirroring the existing kvmppc_virtmode_do_h_enter()
> helper.
>
> For resize_hpt_rehash_hpte(), place preempt_disable() before the
> try_lock_hpte() spin loop and preempt_enable() after unlock_hpte() at
> the function exit.
>
> [1] https://git.kernel.org/powerpc/c/abbbe5ff83e7c9ed3a4d61b73011f1df7bf87907
>
> Fixes: 6165d5dd99db ("KVM: PPC: Book3S HV: add virtual mode handlers for HPT hcalls and page faults")
> Cc: stable@vger.kernel.org # v5.14+
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> Changes in this version:
> - Separated host-side fixes in book3s_64_mmu_hv.c into a standalone patch
>   (guest-side paths were merged from v1 resend).
> - Previous discussion: https://lore.kernel.org/all/20261007182116.12479-3-amachhiw@linux.ibm.com/
>

Thanks. Looks good to me. Please feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>