From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: sashiko-reviews@lists.linux.dev,
Janosch Frank <frankja@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Michael Mueller <mimu@linux.ibm.com>,
Eric Farman <farman@linux.ibm.com>,
Matthew Rosato <mjrosato@linux.ibm.com>
Subject: Re: [PATCH v2] KVM: s390: Improve floating IRQ injection behavior
Date: Tue, 18 Aug 2026 17:14:52 +0200 [thread overview]
Message-ID: <4f233ae1-2a30-4498-bd5d-2a001c96b2d8@linux.ibm.com> (raw)
In-Reply-To: <20260818163226.68c6bea4.pasic@linux.ibm.com>
Am 18.08.26 um 16:32 schrieb Halil Pasic:
> On Mon, 17 Aug 2026 15:22:41 +0200
> Christian Borntraeger <borntraeger@linux.ibm.com> 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.
next prev parent reply other threads:[~2026-08-18 15:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 12:13 [PATCH v2] KVM: s390: Improve floating IRQ injection behavior Janosch Frank
2026-08-17 12:28 ` sashiko-bot
2026-08-17 13:22 ` Christian Borntraeger
2026-08-18 14:32 ` Halil Pasic
2026-08-18 15:14 ` Christian Borntraeger [this message]
2026-08-18 16:58 ` Halil Pasic
2026-08-19 12:54 ` Janosch Frank
2026-08-19 12:57 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f233ae1-2a30-4498-bd5d-2a001c96b2d8@linux.ibm.com \
--to=borntraeger@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=farman@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox