From: eric.auger@redhat.com (Auger Eric)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs
Date: Tue, 26 Jul 2016 11:54:55 +0200 [thread overview]
Message-ID: <f8e83628-5fb0-70d4-c32c-237d190ec98f@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1607261022330.19896@nanos>
Hi Thomas,
On 26/07/2016 11:00, Thomas Gleixner wrote:
> B1;2802;0cEric,
>
> On Mon, 25 Jul 2016, Auger Eric wrote:
>> On 20/07/2016 11:04, Thomas Gleixner wrote:
>>> On Tue, 19 Jul 2016, Eric Auger wrote:
>>>> + if (ret) {
>>>> + for (; i >= 0; i--) {
>>>> + struct irq_data *d = irq_get_irq_data(virq + i);
>>>> +
>>>> + msi_handle_doorbell_mappings(d, false);
>>>> + }
>>>> + irq_domain_free_irqs(virq, desc->nvec_used);
>>>> + desc->irq = 0;
>>>> + goto error;
>>>
>>> How is that supposed to work? You clear desc->irq and then you call
>>> ops->handle_error.
>>
>> if I don't clear the desc->irq I enter an infinite loop in
>> pci_enable_msix_range.
>>
>> This happens because msix_capability_init and pcie_enable_msix returns 1.
>> In msix_capability_init, at out_avail: we enumerate the msi_desc which have
>> a non zero irq, hence the returned value equal to 1.
>>
>> Currently the only handle_error ops I found, pci_msi_domain_handle_error
>> does not use irq field so works although questionable.
>
> The logic here is: If the allocation does not succeed for the requested number
> of interrupts, we tell the caller how many interrupts we were able to set up.
> So the caller can decide what to do.
>
> In your case you don't want to have a partial allocation, so instead of
> playing silly games with desc->irq you should add a flag which tells the PCI
> code that you are not interested in a partial allocation and that it should
> return an error code instead.
In that case can we consider we even succeeded in allocating 1 MSI? In case the
IOMMU mapping fails, the MSI transaction will never reach the target MSI frame
so it is not usable. So when you mean "partial" I understand we did not succeed
in allocating maxvec IRQs, correct? Here we succeeded in allocating 0 IRQ and still
msi_capability_init returns 1.
msi_capability_init doc-comment says "a positive return value indicates the number of
interrupts which could have been allocated."
I understand allocation success currently only depends on the fact virq was allocated
and set to desc->irq. But with that IOMMU stuff doesn't the criteria changes?
> Something like PCI_DEV_FLAGS_MSI_NO_PARTIAL_ALLOC should do the trick.
>
>> As for the irq_domain_free_irqs I think I can remove it since handled later.
>
> Not only the free_irqs(). You should let the teardown function handle
> everything including your doorbell mapping teardown. It's nothing special and
> free_msi_irqs() at the end of msix_capability_init() will take care of it.
Yep I was forced to call free_irqs myself since free_msi_irqs was doing nothing
due the fact I resetted the irq field. Wrong thing loop ;-)
Thanks
Eric
>
> Thanks,
>
> tglx
>
next prev parent reply other threads:[~2016-07-26 9:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 13:02 [PATCH v11 00/10] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes Eric Auger
2016-07-19 13:02 ` [PATCH v11 01/10] genirq/msi: export msi_get_domain_info Eric Auger
2016-07-19 13:02 ` [PATCH v11 02/10] genirq/msi: msi_compose wrapper Eric Auger
2016-07-19 13:02 ` [PATCH v11 03/10] genirq/irq: introduce msi_doorbell_info Eric Auger
2016-07-19 14:15 ` Thomas Gleixner
2016-07-19 13:02 ` [PATCH v11 04/10] genirq/msi-doorbell: allow MSI doorbell (un)registration Eric Auger
2016-07-19 14:22 ` Thomas Gleixner
2016-07-20 7:50 ` Auger Eric
2016-07-19 13:02 ` [PATCH v11 05/10] genirq/msi-doorbell: msi_doorbell_pages Eric Auger
2016-07-19 14:38 ` Thomas Gleixner
2016-07-20 7:50 ` Auger Eric
2016-07-21 13:38 ` Auger Eric
2016-07-19 13:02 ` [PATCH v11 06/10] genirq/msi-doorbell: msi_doorbell_safe Eric Auger
2016-07-20 8:12 ` Thomas Gleixner
2016-07-21 13:38 ` Auger Eric
2016-07-22 12:44 ` Thomas Gleixner
2016-07-22 14:08 ` Auger Eric
2016-07-19 13:02 ` [PATCH v11 07/10] irqchip/gicv2m: register the MSI global doorbell Eric Auger
2016-07-19 13:02 ` [PATCH v11 08/10] irqchip/gicv3-its: " Eric Auger
2016-07-19 13:02 ` [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs Eric Auger
2016-07-20 9:04 ` Thomas Gleixner
2016-07-25 16:21 ` Auger Eric
2016-07-26 9:00 ` Thomas Gleixner
2016-07-26 9:54 ` Auger Eric [this message]
2016-07-26 11:01 ` Thomas Gleixner
2016-07-19 13:02 ` [PATCH v11 10/10] genirq/msi: use the MSI doorbell's IOVA when requested Eric Auger
2016-07-20 9:09 ` Thomas Gleixner
2016-07-25 16:31 ` Auger Eric
2016-07-26 9:04 ` Thomas Gleixner
2016-07-26 10:02 ` Auger Eric
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=f8e83628-5fb0-70d4-c32c-237d190ec98f@redhat.com \
--to=eric.auger@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).