linux-kernel - Re: MSI, fun for the whole family

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 for Android: free password hash cracker in your pocket

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

Message-ID: <48115F90.1030100@garzik.org>
Date:	Fri, 25 Apr 2008 00:35:28 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Roland Dreier <rdreier@...co.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rene Herman <rene.herman@...access.nl>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, rmk@....linux.org.uk,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: MSI, fun for the whole family

Roland Dreier wrote:
> I think you've fundamentally misunderstood what the PCI spec for MSI
> multi message means.  It is true that if the whole system agrees, then

You seem to be ignoring a key usage...

> an MSI-capable device that supports multiple messages might be allocated
> a range of vectors (MSI is kind of stupid because it only allows
> multiple messages to be generated by varying the low order bits -- MSI-X
> fixes this limitation).  However, the way that these different messages
> are handled is that they are all independent interrupt vectors.
> 
> Now, it is true that the kernel could do something crazy and collapse
> all these interrupt vectors into a single "IRQ" and then tell the
> interrupt handler which vector it was by passing some "metadata" in, but
> why not just give each MSI message it's own IRQ?

The answer is:  the driver might prefer to see the message as it 
arrived, rather than dividing it up into independent vectors.  The 
message itself is a unit of data consistency, and there is value in 
letting the driver see the bounds of that unit.

As it stands now, we only a spray of $N function calls for each message, 
with no notion of "we started processing this set of messages" and "we 
ended processing[...]"

Additionally the bitmask-friendly multi-port architecture of these SATA 
controllers matches nicely with an activity (event) status mask we 
already obtain in almost every driver.

Don't assume that the way Linux supports this stuff today is the best, 
or the only way to do things.  It's not "collapsing all these interrupt 
vectors" -- remember that an expansion occurred, and /avoiding 
expansion/ into multiple vectors for multiple messages may be an optimal 
path for a specific driver application.

	Jeff

--
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/