1. Patchew
  2. linux
  3. View series

[PATCH] RISC-V: KVM: Use raw_spinlock for VMID update critical section

yhchen312@gmail.com posted 1 patch 1 week, 2 days ago 
arch/riscv/kvm/vmid.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
[PATCH] RISC-V: KVM: Use raw_spinlock for VMID update critical section
Posted by yhchen312@gmail.com 1 week, 2 days ago 
From: "Yuhang.chen" <yhchen312@gmail.com>

The VMID update critical section performs an IPI broadcast via
on_each_cpu_mask() on VMID version rollover, which must not be preempted
under PREEMPT_RT. Convert vmid_lock to raw_spinlock_t and use plain
raw_spin_lock()/raw_spin_unlock() (interrupts stay enabled, since
on_each_cpu_mask() requires it).

Assisted-by: YuanSheng:deepseek-v4-pro
Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
Signed-off-by: Yuhang.chen <yhchen312@gmail.com>
---
 arch/riscv/kvm/vmid.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/kvm/vmid.c b/arch/riscv/kvm/vmid.c
index c15bdb1dd8be..21c2b276b55d 100644
--- a/arch/riscv/kvm/vmid.c
+++ b/arch/riscv/kvm/vmid.c
@@ -21,7 +21,7 @@
 static unsigned long vmid_version = 1;
 static unsigned long vmid_next;
 static unsigned long vmid_bits __ro_after_init;
-static DEFINE_SPINLOCK(vmid_lock);
+static DEFINE_RAW_SPINLOCK(vmid_lock);
 
 void __init kvm_riscv_gstage_vmid_detect(void)
 {
@@ -78,14 +78,14 @@ void kvm_riscv_gstage_vmid_update(struct kvm_vcpu *vcpu)
 	if (!kvm_riscv_gstage_vmid_ver_changed(vmid))
 		return;
 
-	spin_lock(&vmid_lock);
+	raw_spin_lock(&vmid_lock);
 
 	/*
 	 * We need to re-check the vmid_version here to ensure that if
 	 * another vcpu already allocated a valid vmid for this vm.
 	 */
 	if (!kvm_riscv_gstage_vmid_ver_changed(vmid)) {
-		spin_unlock(&vmid_lock);
+		raw_spin_unlock(&vmid_lock);
 		return;
 	}
 
@@ -117,7 +117,7 @@ void kvm_riscv_gstage_vmid_update(struct kvm_vcpu *vcpu)
 
 	WRITE_ONCE(vmid->vmid_version, READ_ONCE(vmid_version));
 
-	spin_unlock(&vmid_lock);
+	raw_spin_unlock(&vmid_lock);
 
 	/* Request G-stage page table update for all VCPUs */
 	kvm_for_each_vcpu(i, v, vcpu->kvm)
-- 
2.34.1
Re: [PATCH] RISC-V: KVM: Use raw_spinlock for VMID update critical section
Posted by Sebastian Andrzej Siewior 1 week, 1 day ago 
On 2026-07-16 14:40:11 [+0800], yhchen312@gmail.com wrote:
> From: "Yuhang.chen" <yhchen312@gmail.com>
> 
> The VMID update critical section performs an IPI broadcast via
> on_each_cpu_mask() on VMID version rollover, which must not be preempted
> under PREEMPT_RT.

Here you state _why_ it must not be preempted. What would be the worst
that could happen.

>                   Convert vmid_lock to raw_spinlock_t and use plain
That part starting with "Convert" belongs into into a new line.

> raw_spin_lock()/raw_spin_unlock() (interrupts stay enabled, since
> on_each_cpu_mask() requires it).
> 
> Assisted-by: YuanSheng:deepseek-v4-pro
> Co-developed-by: Quan Zhou <zhouquan@iscas.ac.cn>
> Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn>
> Signed-off-by: Yuhang.chen <yhchen312@gmail.com>

Sebastian
Re: [PATCH] RISC-V: KVM: Use raw_spinlock for VMID update critical section
Posted by Yuhang.chen 3 days, 3 hours ago 
Hi Sebastian,

thanks for having a look.

On 2026-07-17 06:51:37 [+0000], Sebastian Andrzej Siewior wrote:
> Here you state _why_ it must not be preempted. What would be the worst
> that could happen.

The worst case is an unbounded hold of vmid_lock that stalls guest entry
system-wide. On rollover the section bumps vmid_version and then broadcasts
a guest-TLB flush via on_each_cpu_mask(..., wait=1) before assigning a
fresh VMID. Under PREEMPT_RT a plain spinlock_t is preemptible, so the
holder could be scheduled out while still waiting for that broadcast flush
to finish and keep vmid_lock held for an unbounded scheduling delay; every
other vCPU reaching the VMID-(re)assignment path on its way into the guest
would then block on the lock. The rollover is otherwise a short critical
section (a version bump plus one IPI), so keeping it non-preemptible with
raw_spinlock_t bounds its hold time.

I'll fold that into the commit log.

> That part starting with "Convert" belongs into into a new line.

Will fix in v2.

I'll send v2 with both changes.

  Yuhang
Re: [PATCH] RISC-V: KVM: Use raw_spinlock for VMID update critical section
Posted by sashiko-bot@kernel.org 1 week, 2 days ago 
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Race condition during VMID rollover allows a vCPU to transiently execute in guest mode with a stale VMID, compromising cross-VM isolation.
- [High] Integer overflow in the VMID generation counter (vmid_version) on 32-bit systems causes a cross-VM isolation break.
--

--- Patch [1]: [PATCH] RISC-V: KVM: Use raw_spinlock for VMID update critical section ---
commit 7d899ea43321661351b3cdd958ba47c38d85eeed
Author: Yuhang.chen <yhchen312@gmail.com>

RISC-V: KVM: Use raw_spinlock for VMID update critical section

This commit converts the vmid_lock to a raw_spinlock_t to prevent
preemption during the VMID update section under PREEMPT_RT. The update
path performs an IPI broadcast which requires preemption to be disabled.

> diff --git a/arch/riscv/kvm/vmid.c b/arch/riscv/kvm/vmid.c
> index 3b426c800480c..33efde4bb9d75 100644
> --- a/arch/riscv/kvm/vmid.c
> +++ b/arch/riscv/kvm/vmid.c
> @@ -20,7 +20,7 @@
>  static unsigned long vmid_version = 1;
>  static unsigned long vmid_next;
>  static unsigned long vmid_bits __ro_after_init;
> -static DEFINE_SPINLOCK(vmid_lock);
> +static DEFINE_RAW_SPINLOCK(vmid_lock);
>  
>  void __init kvm_riscv_gstage_vmid_detect(void)
>  {

[Severity: High]
This is a pre-existing issue, but does this unsigned long counter present an
overflow risk on 32-bit systems?

If a host user rapidly creates and destroys VMs, the 32-bit vmid_version could
wrap back to 0. Since a new VM's kvm_vmid struct is zero-initialized,
kvm_riscv_gstage_vmid_ver_changed() would evaluate (0 != 0) as false:

kvm_riscv_gstage_vmid_ver_changed() {
    ...
    return unlikely(READ_ONCE(vmid->vmid_version) !=
                    READ_ONCE(vmid_version));
}

Could this cause multiple new VMs to share VMID 0, breaking cross-VM isolation
by allowing their memory accesses to hit each other's TLB entries?

[ ... ]

> @@ -118,7 +118,7 @@ void kvm_riscv_gstage_vmid_update(struct kvm_vcpu *vcpu)
>  
>  	WRITE_ONCE(vmid->vmid_version, READ_ONCE(vmid_version));
>  
> -	spin_unlock(&vmid_lock);
> +	raw_spin_unlock(&vmid_lock);
>  
>  	/* Request G-stage page table update for all VCPUs */
>  	kvm_for_each_vcpu(i, v, vcpu->kvm)
>  		kvm_make_request(KVM_REQ_UPDATE_HGATP, v);

[Severity: Critical]
This isn't a bug introduced by this patch, but does dropping the lock before
making the requests open a race window?

If the lock is released after updating vmid_version but before setting
KVM_REQ_UPDATE_HGATP, could a concurrent vCPU from the same VM observe the
new vmid_version without the lock?

If it sees no pending requests, it might proceed to enter the guest with a
stale VMID. If a global VMID rollover just occurred, could this stale VMID
have been re-assigned to a different VM, causing an isolation break?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716064011.2387501-1-yhchen312@gmail.com?part=1

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.