From: Matthew Wilcox <matthew@wil.cx>
To: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
grundler@parisc-linux.org, mingo@elte.hu, tglx@linutronix.de,
jgarzik@pobox.com, linux-ide@vger.kernel.org,
suresh.b.siddha@intel.com, benh@kernel.crashing.org,
jbarnes@virtuousgeek.org, rdunlap@xenotime.net,
mtk.manpages@gmail.com, Matthew Wilcox <willy@linux.intel.com>
Subject: Re: [PATCH] PCI: Add support for multiple MSI
Date: Fri, 11 Jul 2008 03:45:20 -0600 [thread overview]
Message-ID: <20080711094520.GQ14894@parisc-linux.org> (raw)
In-Reply-To: <487719AC.9070609@jp.fujitsu.com>
On Fri, Jul 11, 2008 at 05:28:28PM +0900, Hidetoshi Seto wrote:
> Hi,
>
> First of all, it seems that mask/unmask of MSI has problems.
> - Per-vector masking is optional for MSI, so I think that allocating
> multiple messages for a function without masking capability would be
> not good idea, since all vector in the block will be masked/unmasked
> at once without any agreement.
> - Even if the function supports per-vector masking, current
> mask/unmask_msi_irq() functions assume that MSI uses only one vector,
> therefore they only set/unset the first bit of the maskbits which
> for the first vector of the block. The bits for other vectors are
> initialized as 'masked' but no one unmask them.
Thank you for pointing out the problems with masking. The device I am
testing with does not support per-vector masking, so I have not paid
attention to this.
To your first point, if the function does not support per-vector
masking, I think it's OK to mask/unmask all vectors at once. But we
must be careful to manage this correctly in software; if we disable IRQ
496, disable IRQ 497, then enable IRQ 497, we must not enable IRQ 496 at
that time. I think we can solve this problem, but I must think about it
some more.
The second point is a simple bug that should be easy to fix. Thank you
for pointing it out.
> Matthew Wilcox wrote:
> > + * Allocate IRQs for a device with the MSI capability.
> > + * This function returns a negative errno if an error occurs. If it
> > + * is unable to allocate the number of interrupts requested, it returns
> > + * the number of interrupts it might be able to allocate. If it successfully
> > + * allocates at least the number of interrupts requested, it returns 0 and
> > + * updates the @dev's irq member to the lowest new interrupt number; the
> > + * other interrupt numbers allocated to this device are consecutive.
> > + */
> > +int pci_enable_msi_block(struct pci_dev *dev, unsigned int nvec)
> > {
> > int status;
> >
> > - status = pci_msi_check_device(dev, 1, PCI_CAP_ID_MSI);
> > + /* MSI only supports up to 32 interrupts */
> > + if (nvec > 32)
> > + return 32;
>
> I think we should return -EINVAL here.
> No one guarantee that 32 interrupts is able to be allocate at this time.
>
> And also I think -EINVAL should be returned if nvec is greater than
> the number of encoded in the function's "Multiple Message Capable", but
> I could not find any mention about handling of such over-capability request
> in PCI Bus Spec. 3.0.
It would be outside the scope of the PCI Bus Specification. I think
you're right that we should check the MMC bits; but I think we should
tell the driver to request a lower number, not return -EINVAL.
Thanks for your comments.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2008-07-11 9:45 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-11 0:57 Multiple MSI, take 3 Matthew Wilcox
2008-07-11 0:59 ` [PATCH] PCI MSI: Replace 'type' with 'is_msix' Matthew Wilcox
2008-07-11 0:59 ` [PATCH] PCI: Add support for multiple MSI Matthew Wilcox
2008-07-11 8:28 ` Hidetoshi Seto
2008-07-11 9:45 ` Matthew Wilcox [this message]
2008-07-12 3:45 ` Benjamin Herrenschmidt
2008-07-11 1:00 ` [PATCH] Rewrite MSI-HOWTO Matthew Wilcox
2008-09-26 6:42 ` Grant Grundler
2008-07-11 1:00 ` [PATCH] AHCI: Request multiple MSIs Matthew Wilcox
2008-07-11 1:00 ` [PATCH] x86-64: Support for " Matthew Wilcox
2008-07-11 4:50 ` Kenji Kaneshige
2008-07-11 8:50 ` Matthew Wilcox
2008-07-14 1:08 ` Kenji Kaneshige
2008-07-11 10:06 ` Multiple MSI, take 3 Eric W. Biederman
2008-07-11 10:23 ` Matthew Wilcox
2008-07-11 10:32 ` David Miller
2008-07-11 10:41 ` Matthew Wilcox
2008-07-11 11:05 ` Eric W. Biederman
2008-07-11 11:34 ` Eric W. Biederman
2008-07-11 12:17 ` Matthew Wilcox
2008-07-11 15:10 ` Matthew Wilcox
2008-07-11 21:59 ` Suresh Siddha
2008-07-11 22:59 ` Eric W. Biederman
2008-07-11 23:15 ` Suresh Siddha
2008-07-11 23:59 ` Eric W. Biederman
2008-07-12 3:52 ` Benjamin Herrenschmidt
2008-07-12 4:41 ` Eric W. Biederman
2008-07-12 7:36 ` Benjamin Herrenschmidt
2008-07-13 22:30 ` Eric W. Biederman
2008-07-13 22:44 ` Benjamin Herrenschmidt
2008-07-13 23:29 ` Eric W. Biederman
2008-07-14 0:17 ` Benjamin Herrenschmidt
2008-07-14 0:44 ` David Miller
2008-07-14 2:03 ` Eric W. Biederman
2008-07-14 3:19 ` David Miller
2008-09-26 5:30 ` Jike Song
2008-09-27 19:04 ` Matthew Wilcox
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=20080711094520.GQ14894@parisc-linux.org \
--to=matthew@wil.cx \
--cc=benh@kernel.crashing.org \
--cc=grundler@parisc-linux.org \
--cc=jbarnes@virtuousgeek.org \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtk.manpages@gmail.com \
--cc=rdunlap@xenotime.net \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=willy@linux.intel.com \
/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).