[PW_SID:1126347] [v3] RISC-V: KVM: Serialize virtual interrupt pending state updates#2268
[PW_SID:1126347] [v3] RISC-V: KVM: Serialize virtual interrupt pending state updates#2268linux-riscv-bot wants to merge 1 commit into
Conversation
RISC-V KVM tracks guest interrupt state with two bitmaps:
- irqs_pending: interrupts that should be visible to the guest
- irqs_pending_mask: interrupts whose pending state changed
The current code updates those bitmaps with independent atomic bitops
and assumes a multiple-producer, single-consumer protocol. That model
does not actually hold.
kvm_riscv_vcpu_sync_interrupts() is not a pure consumer. When the guest
changes guest-visible HVIP state, sync_interrupts() writes both
irqs_pending and irqs_pending_mask to reflect the new guest state back
into KVM state. As a result, irqs_pending and irqs_pending_mask form a
single logical state transition, but they are not updated atomically as
a pair.
This allows a race where a newly injected interrupt is lost. For
example:
CPU0 CPU1
---- ----
kvm_riscv_vcpu_set_interrupt(VS_SOFT)
set_bit(VS_SOFT, irqs_pending)
kvm_riscv_vcpu_sync_interrupts()
sees guest-cleared HVIP.VSSIP
sets irqs_pending_mask
clears irqs_pending
set_bit(VS_SOFT, irqs_pending_mask)
kvm_vcpu_kick()
After that interleaving, a later flush can update HVIP without VSSIP
even though a new virtual interrupt was injected. In practice, the
guest can remain blocked in WFI with work pending.
The same pending/mask protocol is shared by VS soft interrupts, PMU
overflow delivery, and AIA high interrupt synchronization, so the race
is not limited to one interrupt source.
Fix this by serializing all updates to irqs_pending and
irqs_pending_mask with a per-vCPU raw spinlock. This keeps the pending
bit and the dirty mask as one state transition across:
- set/unset interrupt
- guest HVIP sync
- interrupt flush to guest CSR state
- vCPU reset
- AIA CSR writes that clear dirty state
Use non-atomic bitmap operations while holding the lock. Hold the lock
across the AIA sync, flush, and pending checks as well, so both bitmap
words share the same serialization domain.
This intentionally replaces the existing lockless protocol instead of
trying to repair it with additional barriers. The problem is not memory
ordering on a single field; it is that two separate bitmaps encode one
shared state machine while both producers and sync paths can modify
them. A per-vCPU raw spinlock keeps the fix small, local, and suitable
for backporting.
Fixes: cce69af ("RISC-V: KVM: Implement VCPU interrupts and requests handling")
Cc: stable@vger.kernel.org
Signed-off-by: Xie Bo <xb@ultrarisc.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v3] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
2 participants
PR for series 1126347 applied to workflow__riscv__fixes
Name: [v3] RISC-V: KVM: Serialize virtual interrupt pending state updates
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=1126347
Version: 3