From: Douglas Freimuth <freimuth@linux.ibm.com>
To: Matthew Rosato <mjrosato@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: Mon, 4 May 2026 09:21:44 -0400 [thread overview]
Message-ID: <b81184c5-484b-4c69-a029-104ba37127fb@linux.ibm.com> (raw)
In-Reply-To: <cff05849-c937-4611-8776-d654e225e5cc@linux.ibm.com>
On 4/29/26 12:11 PM, Matthew Rosato wrote:
>
>> +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;
>
>
Thanks. This function was a bit of sideshow and kind of an after thought
but that said I was determined to give the caller a return code. It
really wanted a WARN_ON_ONCE. That works better here.
prev parent reply other threads:[~2026-05-04 13:21 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
2026-05-04 13:21 ` Douglas Freimuth [this message]
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=b81184c5-484b-4c69-a029-104ba37127fb@linux.ibm.com \
--to=freimuth@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@kernel.org \
--cc=frankja@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=mjrosato@linux.ibm.com \
--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