public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


             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