Re: [PATCH v3 3/3] KVM: s390: Introducing kvm_arch_set_irq_inatomic fast inject

[Sean Christopherson <seanjc@google.com>]

On Mon, Apr 06, 2026, Matthew Rosato wrote:
> On 4/6/26 2:44 AM, Douglas Freimuth wrote:
> > S390 needs a fast path for irq injection, and along those lines we 
> > introduce kvm_arch_set_irq_inatomic. Instead of placing all interrupts on
> > the global work queue as it does today, this patch provides a fast path for
> > irq injection.
> > 
> > The inatomic fast path cannot lose control since it is running with
> > interrupts disabled. This meant making the following changes that exist on 
> > the slow path today. First, the adapter_indicators page needs to be mapped
> > since it is accessed with interrupts disabled, so we added map/unmap
> > functions. Second, access to shared resources between the fast and slow 
> > paths needed to be changed from mutex and semaphores to spin_lock's.
> > Finally, the memory allocation on the slow path utilizes GFP_KERNEL_ACCOUNT
> > but we had to implement the fast path with GFP_ATOMIC allocation. Each of
> > these enhancements were required to prevent blocking on the fast inject
> > path.
> > 
> > Fencing of Fast Inject in Secure Execution environments is enabled in the
> > patch series by not mapping adapter indicator pages. In Secure Execution
> > environments the path of execution available before this patch is followed.
> > 
> > Statistical counters have been added to enable analysis of irq injection on
> > the fast path and slow path including io_390_inatomic, io_flic_inject_airq,
> > io_set_adapter_int and io_390_inatomic_adapter_masked.
> > 
> > Signed-off-by: Douglas Freimuth <freimuth@linux.ibm.com>
> 
> 
> Sashiko complains about PREEMPT_RT kernels and spinlocks being sleepable
> in this case which would break the whole point of kvm_arch_set_irq_inatomic.

Just make it a raw spinlock so that it stays an actual spinlock.

> I suspect actually the kvm_arch_set_irq_inatomic() call itself shouldn't
> be used in this case, or in other words it wouldn't be an issue with
> just this s390 implementation but rather all of arch implementations?
> 
> I did not try enabling it and running a test, but I did do some
> searching of the codebase and I can found at least 1 spinlock acquired
> somewhere along the inatomic path for the existing implementations...
> 
> longarch (pch_pic_set_irq)

I doubt anyone runs PREEMPT_RT VMs on LoongArch at this point.

> arm64 (vgic_its_inject_cached_translation)

Uses raw.

> powerpc (icp_deliver_irq)

Presumably arch_spin_lock() is also a "raw" version?  PPC KVM is barely maintained
at this point, so I wouldn't worry much about it.

> riscv (kvm_riscv_aia_aplic_inject)

Uses "raw".

> For x86 I didn't find a spinlock -- maybe I didn't look hard enough! --
> but I did find a path that uses RCU (kvm_irq_delivery_to_apic_fast)
> which AFAIU would also become preemptible under PREEMPT_RT.

This isn't about becoming preemptible per se, it's about non-raw spinlocks
becoming sleepable locks.  RCU can be made preemptible, but rcu_read_lock()
doesn't become sleepable.

> So for this series it seems reasonable to me to proceed as-is, with an
> open question whether there should be a KVM-wide avoidance of
> kvm_arch_set_irq_inatomic() under PREEMPT_RT?

s390 should use a raw spinlock, same as arm64 and RISC-V.