From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Douglas Freimuth <freimuth@linux.ibm.com>,
borntraeger@linux.ibm.com, imbrenda@linux.ibm.com,
frankja@linux.ibm.com, david@kernel.org, hca@linux.ibm.com,
gor@linux.ibm.com, agordeev@linux.ibm.com, svens@linux.ibm.com,
kvm@vger.kernel.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/3] KVM: s390: Introducing kvm_arch_set_irq_inatomic fast inject
Date: Wed, 29 Apr 2026 12:11:26 -0400 [thread overview]
Message-ID: <cff05849-c937-4611-8776-d654e225e5cc@linux.ibm.com> (raw)
In-Reply-To: <20260423235316.3665-4-freimuth@linux.ibm.com>
> +static int adapter_indicators_set_fast(struct kvm *kvm,
> + struct s390_io_adapter *adapter,
> + struct kvm_s390_adapter_int *adapter_int,
> + int setbit)
> +{
> + unsigned long bit;
> + int summary_set;
> + struct s390_map_info *ind_info, *summary_info;
> + void *map;
> +
> + raw_spin_lock(&adapter->maps_lock);
> + ind_info = get_map_info(adapter, adapter_int->ind_addr);
> + if (!ind_info) {
> + raw_spin_unlock(&adapter->maps_lock);
> + return -EWOULDBLOCK;
> + }
> + map = page_address(ind_info->page);
> + bit = get_ind_bit(ind_info->addr, adapter_int->ind_offset, adapter->swap);
> + if (setbit)
> + set_bit(bit, map);
> + else
> + clear_bit(bit, map);
Hmm, I don't know about this. In my comment on v2 I was only concerned
about undoing the setting of the summary indicator as that will be used
on the slow path to decide whether or not we need to inject an interrupt
in addition to setting the indicator bits.
I think we should drop the else clear_bit() here. If _fast already set
it and we are now backing out to the slow path, then it will stay on all
the way through the slow path and that should be OK.
> + summary_info = get_map_info(adapter, adapter_int->summary_addr);
> + if (!summary_info) {
> + raw_spin_unlock(&adapter->maps_lock);
> + return -EWOULDBLOCK;
> + }
> + map = page_address(summary_info->page);
> + bit = get_ind_bit(summary_info->addr, adapter_int->summary_offset,
> + adapter->swap);
> + if (setbit)
> + summary_set = test_and_set_bit(bit, map);
> + else
> + summary_set = test_and_clear_bit(bit, map);
I had to go back and refresh myself about WHY we needed to 'undo' our
prior setting of the summary bit specifically.
The reason is that, if we need to fall back to the slow path, that code
will see the summary bit already on and therefore not inject an
interrupt believing that the thread that initially set the summary bit
did that. But, if we fell back from the _fast path via -EWOULDBLOCK
after setting the summary indicator, no interrupt was ever injected at
that time.
So my point: this _really_ deserves some comment blocks describing the
purpose of setbit + a specific statement that it's OK to clear this
summary bit now when setbit=0 but then the caller must re-drive this
summary indication again via adapter_indicators_set().
[...]
> +int kvm_arch_set_irq_inatomic(struct kvm_kernel_irq_routing_entry *e,
> + struct kvm *kvm, int irq_source_id, int level,
> + bool line_status)
> +{
> + int ret, setbit;
> + struct s390_io_adapter *adapter;
> + struct kvm_s390_float_interrupt *fi = &kvm->arch.float_int;
> + struct kvm_s390_interrupt_info *inti;
> + struct kvm_s390_interrupt s390int = {
> + .type = KVM_S390_INT_IO(1, 0, 0, 0),
> + .parm = 0,
> + };
> +
> + kvm->stat.io_390_inatomic++;
> +
> + /* We're only interested in the 0->1 transition. */
> + if (!level)
> + return -EWOULDBLOCK;
> + if (e->type != KVM_IRQ_ROUTING_S390_ADAPTER)
> + return -EWOULDBLOCK;
> +
> + adapter = get_io_adapter(kvm, e->adapter.adapter_id);
> + if (!adapter)
> + return -EWOULDBLOCK;
> +
> + s390int.parm64 = isc_to_int_word(adapter->isc);
> + setbit = 1;
> + ret = adapter_indicators_set_fast(kvm, adapter, &e->adapter, setbit);
> + if (ret < 0)
> + return -EWOULDBLOCK;
> + if (!ret || adapter->masked) {
> + kvm->stat.io_390_inatomic_adapter_masked++;
> + return 0;
> + }
> +
> + inti = kzalloc_obj(*inti, GFP_ATOMIC);
> + if (!inti)
You need to undo the summary bit indication on this path as well.
[...]
> -static void __kvm_inject_pfault_token(struct kvm_vcpu *vcpu, bool start_token,
> - unsigned long token)
> +static int __kvm_inject_pfault_token(struct kvm_vcpu *vcpu, bool start_token,
> + unsigned long token)
> {
> struct kvm_s390_interrupt inti;
> struct kvm_s390_irq irq;
> + struct kvm_s390_interrupt_info *inti_mem = NULL;
>
> if (start_token) {
> irq.u.ext.ext_params2 = token;
> irq.type = KVM_S390_INT_PFAULT_INIT;
> WARN_ON_ONCE(kvm_s390_inject_vcpu(vcpu, &irq));
> } else {
> + inti_mem = kzalloc_obj(*inti_mem, GFP_KERNEL_ACCOUNT);
> + if (!inti_mem)
> + return -ENOMEM;
To match the other nonzero cases here, rather than making
__kvm_inject_pfault_token() return a value can you leave it a void
return and then just do something like:
if (WARN_ON_ONCE(!inti_mem))
return;
next prev parent reply other threads:[~2026-04-29 16:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 23:53 [PATCH v4 0/3] KVM: s390: Introducing kvm_arch_set_irq_inatomic Fast Inject Douglas Freimuth
2026-04-23 23:53 ` [PATCH v4 1/3] KVM: s390: Add map/unmap ioctl and clean mappings post-guest Douglas Freimuth
2026-04-29 14:44 ` Matthew Rosato
2026-04-30 15:31 ` Claudio Imbrenda
2026-05-05 17:21 ` Douglas Freimuth
2026-04-30 20:10 ` Matthew Rosato
2026-04-30 21:05 ` Douglas Freimuth
2026-04-23 23:53 ` [PATCH v4 2/3] KVM: s390: Enable adapter_indicators_set to use mapped pages Douglas Freimuth
2026-04-23 23:53 ` [PATCH v4 3/3] KVM: s390: Introducing kvm_arch_set_irq_inatomic fast inject Douglas Freimuth
2026-04-29 16:11 ` Matthew Rosato [this message]
2026-05-04 13:21 ` Douglas Freimuth
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=cff05849-c937-4611-8776-d654e225e5cc@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=freimuth@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=svens@linux.ibm.com \
/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