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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.