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

[Matthew Rosato <mjrosato@linux.ibm.com>]

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.

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)
arm64 (vgic_its_inject_cached_translation)
powerpc (icp_deliver_irq)
riscv (kvm_riscv_aia_aplic_inject)

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.

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?