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

["Yuhang.chen" <yhchen312@gmail.com>]

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