Re: [PATCH v2] KVM: s390: Improve floating IRQ injection behavior
Christian Borntraeger <[email protected]>
| Newsgroups | dev.linux.lists.sashiko-reviews,org.kernel.vger.kvm,org.kernel.vger.linux-s390 |
|---|---|
| Message-ID | <[email protected]> |
Am 18.08.26 um 16:32 schrieb Halil Pasic: > On Mon, 17 Aug 2026 15:22:41 +0200 > Christian Borntraeger <[email protected]> wrote: > >>>> + irq_pend_mask = inti_to_irq_pend_mask(inti); >>>> for (sigcpu = kvm->arch.float_int.last_sleep_cpu; ; sigcpu++) { >>>> sigcpu %= online_vcpus; >>>> dst_vcpu = kvm_get_vcpu(kvm, sigcpu); >>>> - if (!is_vcpu_stopped(dst_vcpu)) >>>> + if (!is_vcpu_stopped(dst_vcpu) && >>>> + deliverable_irqs(dst_vcpu) & irq_pend_mask) >>>> break; >>>> /* avoid endless loops if all vcpus are stopped */ >>>> if (nr_tries++ >= online_vcpus) >>>> return; >>> >>> [Severity: High] >>> Does this code drop the interrupt kick entirely if all vCPUs currently >>> have their interrupt masks closed? >> >> I think this is a corner case but still a valid finding. We can probably consider this >> slowpath and wakeup/set cpuflags for ALL cpus? maybe after doing 2 rounds instead of one? > > With GISA, I think the FW is supposed to deliver the floating interrupts > without dropping the vCPU out of SIE. I'm not 100% sure but I think we > can rely on that mechanism for the CPUs that are in SIE. Without GISA, > I think, it is reasonable to assume that vCPUs don't keep running for > ever. It has been a while since I have looked at this code, but I think > the SIE exit path would catch this. If that is true we would not really > lose initiative, but just see delayed interrupt delivery. > > Sleeping vCPUs on the other hand are not of interest in this context, I > think. This is all corner case handling. Imagine one CPU running with IO disabled and all other CPUs sleeping. If now the "opportunistic" wakeup fails the GISA IO interrupt will never be delivered unless there is another wakeup. In reality this is a will not happen, but see the latest kvm unit test patch from Janosch and it might also create latencies, the "pick one CPU to deliver and wake it up if normal processing does not work" obviously has a hole in specific cases.