RISC-V: KVM: Fix IPI delivery for out-of-order vcpu_id

PATCH In review Xiaofeng Yuan 4 participants 4 messages Sep 17 – Oct 9

Subsystems (4)

Stable branch KVM RISC-V KVM RISC-V

lore

Share & tools

lore

Xiaofeng Yuan

author

2026-09-17 12:20 UTC #0 lore raw

PATCH 1/1 RISC-V: KVM: Fix IPI delivery for out-of-order vcpu_id

The SBI IPI handler walks vCPUs with kvm_for_each_vcpu(), which iterates by vcpu_idx (creation order) rather than vcpu_id order. Since vcpu_id can be assigned out of order by userspace, a vCPU whose hart_bit falls outside the XLEN-bit hart_mask range may be reached before vCPUs the mask actually targets. In that case the handler jumps to "done" and stops sending IPIs, leaving valid target vCPUs without an interrupt.

Replace the early "goto done" with "continue" so vCPUs outside the hart_mask range are skipped without aborting the loop.

Reproduced with a minimal userspace VMM driving KVM inside a QEMU (RISC-V virt) guest: three vCPUs are created with ids 100, 0, 1 (in creation order) and sbi_send_ipi(hart_mask=bit0, hbase=0) is called from vcpu_id 1. Before this change the IPI is dropped and the ecall returns SBI_ERR_INVALID_PARAM; with this change the IPI is delivered and the ecall returns SBI_SUCCESS.

Fixes 0611f78f83c9 ("riscv: KVM: Fix SBI IPI error generation")

Cc [email protected]

Signed-off-by Xiaofeng Yuan <[email protected]>

---
 arch/riscv/kvm/vcpu_sbi_replace.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

arch/riscv/kvm/vcpu_sbi_replace.c +10 -2

index 506a510b6..c2f1f7f26 100644
@@ -64,8 +64,17 @@ static int kvm_sbi_ext_ipi_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
 			if (tmp->vcpu_id < hbase)
 				continue;
 			hart_bit = tmp->vcpu_id - hbase;
+			/*
+			 * kvm_for_each_vcpu() walks kvm->vcpus[] by
+			 * vcpu_idx, i.e. the creation order, which has
+			 * nothing to do with the vcpu_id (hart id) space
+			 * that the SBI IPI operates on. vcpu_ids need not
+			 * increase along the iteration, so harts outside
+			 * the hart_mask window must be skipped instead of
+			 * aborting the loop.
+			 */
 			if (hart_bit >= __riscv_xlen)
-				goto done;
+				continue;
 			if (!(hmask & (1UL << hart_bit)))
 				continue;
 		}

@@ -76,7 +85,6 @@ static int kvm_sbi_ext_ipi_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
 		kvm_riscv_vcpu_pmu_incr_fw(tmp, SBI_PMU_FW_IPI_RCVD);
 	}
 
-done:
 	if (hbase != -1UL && (hmask ^ sentmask))
 		retdata->err_val = SBI_ERR_INVALID_PARAM;

Signature · 1 line

2.34.1

Troy Mitchell

Reviewed-by on v1 1/1

2026-09-21 10:00 UTC #1 lore raw

Quoted 18 lines · Xiaofeng Yuan

The SBI IPI handler walks vCPUs with kvm_for_each_vcpu(), which iterates by vcpu_idx (creation order) rather than vcpu_id order. Since vcpu_id can be assigned out of order by userspace, a vCPU whose hart_bit falls outside the XLEN-bit hart_mask range may be reached before vCPUs the mask actually targets. In that case the handler jumps to "done" and stops sending IPIs, leaving valid target vCPUs without an interrupt.
Replace the early "goto done" with "continue" so vCPUs outside the hart_mask range are skipped without aborting the loop.
Reproduced with a minimal userspace VMM driving KVM inside a QEMU (RISC-V virt) guest: three vCPUs are created with ids 100, 0, 1 (in creation order) and sbi_send_ipi(hart_mask=bit0, hbase=0) is called from vcpu_id 1. Before this change the IPI is dropped and the ecall returns SBI_ERR_INVALID_PARAM; with this change the IPI is delivered and the ecall returns SBI_SUCCESS.

Quoted 4 lines

Fixes 0611f78f83c9 ("riscv: KVM: Fix SBI IPI error generation")
Cc [email protected]
Suggested-by Andrew Jones <[email protected]>
Signed-off-by Xiaofeng Yuan <[email protected]>

Reviewed-by Troy Mitchell <[email protected]>

Signature · 1 line

Troy Mitchell

Signature · 3 lines

kvm-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kvm-riscv

Nutty.Liu

Reviewed-by on v1 1/1

2026-09-24 10:31 UTC #2 lore raw

In reply to Xiaofeng Yuan

Quoted 38 lines · Xiaofeng Yuan

The SBI IPI handler walks vCPUs with kvm_for_each_vcpu(), which iterates by vcpu_idx (creation order) rather than vcpu_id order. Since vcpu_id can be assigned out of order by userspace, a vCPU whose hart_bit falls outside the XLEN-bit hart_mask range may be reached before vCPUs the mask actually targets. In that case the handler jumps to "done" and stops sending IPIs, leaving valid target vCPUs without an interrupt.
Replace the early "goto done" with "continue" so vCPUs outside the hart_mask range are skipped without aborting the loop.
Reproduced with a minimal userspace VMM driving KVM inside a QEMU (RISC-V virt) guest: three vCPUs are created with ids 100, 0, 1 (in creation order) and sbi_send_ipi(hart_mask=bit0, hbase=0) is called from vcpu_id 1. Before this change the IPI is dropped and the ecall returns SBI_ERR_INVALID_PARAM; with this change the IPI is delivered and the ecall returns SBI_SUCCESS.
Fixes 0611f78f83c9 ("riscv: KVM: Fix SBI IPI error generation")
Cc [email protected]
Suggested-by Andrew Jones <[email protected]>
Signed-off-by Xiaofeng Yuan <[email protected]>
---
  arch/riscv/kvm/vcpu_sbi_replace.c | 12 ++++++++++--
  1 file changed, 10 insertions(+), 2 deletions(-)
arch/riscv/kvm/vcpu_sbi_replace.c +4 -0
index 506a510b6..c2f1f7f26 100644
@@ -64,8 +64,17 @@ static int kvm_sbi_ext_ipi_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
  			if (tmp->vcpu_id < hbase)
  				continue;
  			hart_bit = tmp->vcpu_id - hbase;
+			/*
+			 * kvm_for_each_vcpu() walks kvm->vcpus[] by
+			 * vcpu_idx, i.e. the creation order, which has
+			 * nothing to do with the vcpu_id (hart id) space

arch/riscv/kvm/vcpu_sbi_replace.c static int kvm_sbi_ext_ipi_handler(struct kvm_vcpu *vcpu, struct kvm_run *run, · line 79

Quoted 10 lines

arch/riscv/kvm/vcpu_sbi_replace.c +6 -1

+			 * that the SBI IPI operates on. vcpu_ids need not
+			 * increase along the iteration, so harts outside
+			 * the hart_mask window must be skipped instead of
+			 * aborting the loop.
+			 */
  			if (hart_bit >= __riscv_xlen)
-				goto done;
+				continue;
  			if (!(hmask & (1UL << hart_bit)))
  				continue;

Seems the above two 'if' statements can be combined. Otherwise,

Reviewed-by Nutty Liu <[email protected]>

Thanks,
Nutty

Quoted 9 lines

arch/riscv/kvm/vcpu_sbi_replace.c +0 -1

@@ -76,7 +85,6 @@ static int kvm_sbi_ext_ipi_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
  		kvm_riscv_vcpu_pmu_incr_fw(tmp, SBI_PMU_FW_IPI_RCVD);
  	}
 
-done:
  	if (hbase != -1UL && (hmask ^ sentmask))
  		retdata->err_val = SBI_ERR_INVALID_PARAM;

Anup Patel

maintainer Reviewed-by on v1 1/1

2026-10-09 19:52 UTC #3 lore raw

In reply to Xiaofeng Yuan

Quoted 19 lines · Xiaofeng Yuan

The SBI IPI handler walks vCPUs with kvm_for_each_vcpu(), which iterates by vcpu_idx (creation order) rather than vcpu_id order. Since vcpu_id can be assigned out of order by userspace, a vCPU whose hart_bit falls outside the XLEN-bit hart_mask range may be reached before vCPUs the mask actually targets. In that case the handler jumps to "done" and stops sending IPIs, leaving valid target vCPUs without an interrupt.
Replace the early "goto done" with "continue" so vCPUs outside the hart_mask range are skipped without aborting the loop.
Reproduced with a minimal userspace VMM driving KVM inside a QEMU (RISC-V virt) guest: three vCPUs are created with ids 100, 0, 1 (in creation order) and sbi_send_ipi(hart_mask=bit0, hbase=0) is called from vcpu_id 1. Before this change the IPI is dropped and the ecall returns SBI_ERR_INVALID_PARAM; with this change the IPI is delivered and the ecall returns SBI_SUCCESS.

Quoted 4 lines

Fixes 0611f78f83c9 ("riscv: KVM: Fix SBI IPI error generation")
Cc [email protected]
Suggested-by Andrew Jones <[email protected]>
Signed-off-by Xiaofeng Yuan <[email protected]>

LGTM.

Reviewed-by Anup Patel <[email protected]>

Queued this patch for Linux-7.4

Thanks,
Anup

Quoted 38 lines

---
 arch/riscv/kvm/vcpu_sbi_replace.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

arch/riscv/kvm/vcpu_sbi_replace.c +10 -3

index 506a510b6..c2f1f7f26 100644
@@ -64,8 +64,17 @@ static int kvm_sbi_ext_ipi_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
                        if (tmp->vcpu_id < hbase)
                                continue;
                        hart_bit = tmp->vcpu_id - hbase;
+                       /*
+                        * kvm_for_each_vcpu() walks kvm->vcpus[] by
+                        * vcpu_idx, i.e. the creation order, which has
+                        * nothing to do with the vcpu_id (hart id) space
+                        * that the SBI IPI operates on. vcpu_ids need not
+                        * increase along the iteration, so harts outside
+                        * the hart_mask window must be skipped instead of
+                        * aborting the loop.
+                        */
                        if (hart_bit >= __riscv_xlen)
-                               goto done;
+                               continue;
                        if (!(hmask & (1UL << hart_bit)))
                                continue;
                }

@@ -76,7 +85,6 @@ static int kvm_sbi_ext_ipi_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
                kvm_riscv_vcpu_pmu_incr_fw(tmp, SBI_PMU_FW_IPI_RCVD);
        }
 
-done:
        if (hbase != -1UL && (hmask ^ sentmask))
                retdata->err_val = SBI_ERR_INVALID_PARAM;
 
--

2.34.1