linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).