Re: [PATCH] RISC-V: KVM: Use a raw lock for IMSIC wakeup state

[Andrew Jones]

On Fri, Oct 09, 2026 at 06:37:13PM +0200, Anup Patel wrote:
> On Fri, Oct 9, 2026 at 3:44 PM Andrew Jones
> <andrew.jones@xxxxxxxxxxxxxxxx> wrote:
> >
> > Hi Anup,
> >
> > On Fri, Oct 09, 2026 at 01:45:20PM +0200, Anup Patel wrote:
> > > On Fri, Sep 25, 2026 at 5:51 PM Andrew Jones
> > > <andrew.jones@xxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > kvm_riscv_vcpu_aia_imsic_put() can run from the scheduler preemption
> > > > notifier while the raw runqueue lock is held. Taking vsfile_lock, an
> > > > rwlock_t, there violates the lockdep wait-context rules.
> > > >
> > > > Protect the CPU/HGEI pair with a separate raw spinlock. All updates to
> > > > that pair retain vsfile_lock and take the new lock, while scheduler-out
> > > > uses only the new lock around the HGEIE update. This keeps the wakeup
> > > > setup serialized with VS-file publication and release without bringing
> > > > wider IMSIC operations into a raw critical section.
> > >
> > > Instead of introducing another lock, why not replace
> > > read_lock_irqsave(&imsic->vsfile_lock, flags) with
> > > write_lock_irqsave(&imsic->vsfile_lock, flags) in
> > > kvm_riscv_vcpu_aia_imsic_put() ??
> >
> > Unfortunately, write_lock_irqsave() has the same PREEMPT_RT issue, since
> > rwlock_t is sleepable on RT in both modes.
> >
> 
> I am not fond of nested locking, why not convert vsfile_lock into raw
> spinlock ??
>

We can do that. The reader concurrency the rwlock gave us was only for
tiny sections anyway. I'll send a v2.

Thanks,
drew