linux-kernel - Re: Multiple MSI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Jul 2008 11:10:29 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	michaele@....ibm.com
Cc:	benh@...nel.crashing.org, Matthew Wilcox <matthew@....cx>,
	linux-pci@...r.kernel.org,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Miller <davem@...emloft.net>,
	Dan Williams <dan.j.williams@...el.com>,
	Martine.Silbermann@...com, linux-kernel@...r.kernel.org
Subject: Re: Multiple MSI

On Thursday 03 July 2008, Michael Ellerman wrote:
> On Thu, 2008-07-03 at 14:41 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-07-02 at 21:59 -0600, Matthew Wilcox wrote:
> > > 
> > > 
> > > This is true and worth considering carefully.  Are IRQ numbers a scarce
> > > resource on PowerPC?  They are considerably less scarce than interrupt
> > > vectors are on x86-64.  How hard is it to make IRQ numbers an abundent
> > > resource?  Is it simply a question of increasing NR_IRQS?
> > 
> > Yes, indeed, they aren't really scarce... actually less than the
> > underlying HW vectors in most cases, so it isn't a big issue to add some
> > kind of constraint to the allocator.
> 
> Not scarce, but increasing NR_IRQS makes some static arrays bigger,
> which is not so nice.

Some years ago, we had discussions about getting rid of IRQ numbers
altogether, or at least the requirement to have device drivers know
about them. Does anyone remember what happened to that idea?

I think the concept was that you pass around struct irq_desc pointers
that may or may not be dynamically allocated by the interrupt controller
code.

Another simplification that should really help here is encapsulating
request_irq() per subsystem so that you can do something like

int my_irq(struct pci_dev *dev);
err = pci_request_irq(pci_dev, &my_irq, IRQF_SHARED);

Most PCI drivers should be trivial to convert to this model. If you want
to have multiple MSI/MSI-X interrupts for one PCI device with this model,
you'd need to introduce the number back as an offset, I guess.

	Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/