[PATCH v2] RISC-V: KVM: Convert IMSIC vsfile_lock to a raw spinlock

[Anup Patel]

On Mon, Oct 19, 2026 at 10:46 PM Andrew Jones <andrew.jones at linux.dev> wrote:
>
> On Mon, Oct 19, 2026 at 03:47:09PM +0200, Andrew Jones wrote:
> > kvm_riscv_vcpu_aia_imsic_put() runs from the scheduler preemption
> > notifier with the raw runqueue lock held, so it must not take
> > vsfile_lock, an rwlock_t, which sleeps on PREEMPT_RT. All vsfile_lock
> > critical sections are short, so a raw spinlock is fine.
> >
> > Fixes: 4cec89db80ba ("RISC-V: KVM: Move HGEI[E|P] CSR access to IMSIC virtualization")
> > Signed-off-by: Andrew Jones <andrew.jones at linux.dev>
> > ---
> > v2:
> >  - Convert vsfile_lock to raw_spinlock_t instead of adding a separate
> >    hgei_lock [Anup]
>
> Hi Anup,
>
> Sashiko found an ABBA deadlock with this v2[1]. Making vsfile_lock
> exclusive serializes kvm_riscv_vcpu_aia_imsic_put(), which runs under
> rq->__lock, against the SW-file inject paths, which kick the vCPU
> (pi_lock/rq->__lock) while holding vsfile_lock. Lockdep confirms it with
> an EMUL mode guest, and the host then hangs (I should have tested with
> EMUL before...). v1 doesn't have the problem, since its hgei_lock never
> has anything that wakes tasks nested under it. I tested v1 in both EMUL
> mode and hwaccel mode [again] with lockdep and it's good.
>
> Should we take v1 instead?
>
> [1] https://sashiko.dev/#/patchset/20261019134709.2610129-1-andrew.jones@linux.dev?part=1
>

Okay, we will go ahead with your v1.

Regards,
Anup