From: John Garry <john.garry@huawei.com>
To: Marc Zyngier <maz@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Bjorn Helgaas" <bhelgaas@google.com>
Cc: Linux PCI <linux-pci@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>,
"luojiaxing@huawei.com" <luojiaxing@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: PCI/kernel msi code vs GIC ITS driver conflict?
Date: Tue, 3 Sep 2019 15:09:36 +0100 [thread overview]
Message-ID: <f5e948aa-e32f-3f74-ae30-31fee06c2a74@huawei.com> (raw)
Hi Marc, Bjorn, Thomas,
We've come across a conflict with the kernel/pci msi code and GIC ITS
driver on our arm64 system, whereby we can't unbind and re-bind a PCI
device driver under special conditions. I'll explain...
Our PCI device support 32 MSIs. The driver attempts to allocate msi
vectors with min msi=17, max msi = 32, and affd.pre vectors = 16. For
our test we make nr_cpus = 1 (just anything less than 16).
We find that the pci/kernel msi code gives us 17 vectors, but the GIC
ITS code reserves 32 lpi maps in its_irq_domain_alloc(). The problem
then occurs when unbinding the driver in its_irq_domain_free() call,
where we only clear bits for 17 vectors. So if we unbind the driver and
then attempt to bind again, it fails.
Where the fault lies, I can't say. Maybe the kernel msi code should
always give power of 2 vectors - as I understand, the PCI spec mandates
this. Or maybe the GIC ITS driver has a problem in the free path, as
above. Or maybe the PCI driver should not be allowed to request !power
of 2 min/max vectors.
Opinion?
Thanks in advance,
John
next reply other threads:[~2019-09-03 14:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 14:09 John Garry [this message]
2019-09-03 16:16 ` PCI/kernel msi code vs GIC ITS driver conflict? Marc Zyngier
2019-09-04 8:56 ` John Garry
2019-09-04 10:25 ` Andrew Murray
2019-09-05 8:38 ` Marc Zyngier
2019-09-05 9:39 ` John Garry
2019-09-05 10:02 ` Marc Zyngier
2019-09-05 10:35 ` John Garry
2019-09-05 11:22 ` Marc Zyngier
2019-09-05 13:26 ` John Garry
2019-09-05 13:50 ` Marc Zyngier
2019-09-05 14:23 ` John Garry
2019-09-05 14:32 ` Marc Zyngier
2019-09-05 14:53 ` John Garry
2019-09-05 15:09 ` Marc Zyngier
2019-09-06 11:08 ` [tip: irq/core] irqchip/gic-v3-its: Fix LPI release for Multi-MSI devices tip-bot2 for Marc Zyngier
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=f5e948aa-e32f-3f74-ae30-31fee06c2a74@huawei.com \
--to=john.garry@huawei.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=luojiaxing@huawei.com \
--cc=maz@kernel.org \
--cc=tglx@linutronix.de \
/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