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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.