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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <adamynh5zc7.fsf@cisco.com>
Date:	Fri, 25 Apr 2008 15:44:40 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Jeff Garzik <jeff@...zik.org>
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

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

I can't really understand what this is about.  As things stand now, each
MSI message results in an interrupt, which results in calling the
interrupt handler.  What information from "the message as it arrived" is
being lost other than the precise contents of the PCI transaction, which
is system dependent and of no more interest to the driver than what ball
number a PCI wire interrupt is hooked up to?

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

I also don't know what you mean about "bitmask-friendly".  The AHCI spec
that you mentioned pretty clearly talks about having an MSI message per
port, rather than putting a bitmask of ports in the message.  Given that
AHCI supports 32 ports, and MSI messages only are 16 bits long (of which
only 5 bits can be changed by the device), I don't see how you expect
this bitmask to be encoded.

It seems to me that if the kernel supported multiple MSI messages in the
same way it handles multiple MSI-X messages, by giving a different IRQ
number for each message, this would be ideal for a driver... you would
basically do

	for (i = 0; i < dev->num_ports; i++)
		request_irq(dev->msi_vector[i],
			    port_irq_handler, 0,
			    "name", &dev->port[i]);

and then your interrupt handler could look like

irqreturn_t port_irq_handler(int irq, void *port_ptr)
{
	struct my_port *port = port_ptr;
	//...

which is very clean and saves you from having to look up any mask of
ports.

So it might be nice to handle multiple MSI messages, but it's fairly
ugly (both because of the current Linux interrupt handling structure and
also because the MSI spec is somewhat broken), but given that most
devices are moving to MSI-X, it's not clear that it's worth working on
this.  And I don't see any reason why MSI would require changes to the
IRQ handler prototype.

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

What expansion occurrs?  On x86, having a different vector for each MSI
message it pretty fundamental to the way the hardware handles interrupts.

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