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-next>] [day] [month] [year] [list]
Message-ID: <c3d0340b0710301413r2607ee08x8b27c5bffa43f1c4@mail.gmail.com>
Date:	Tue, 30 Oct 2007 13:13:41 -0800
From:	"Shawn Jin" <shawnxjin@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Multiple MSI messages support

Hi,

If this is really off-topic here, I apologize first. But I cannot
think a better place to ask this particular question.

I understand that the current PCI subsystem or linux kernel (x86)
supports only one message when MSI is enabled even for devices having
multiple MSI messages. But why? Is this a limitation solely due to the
OS or due to the x86 APIC?

I know the current linux kernel (2.6.23) changed MSI message data
format a little bit to support other architectures. But some older
version (e.g. 2.6.18) defined a specific format for the MSI msg data
in a way that 8 bits contain the irq number and the other 8 bits have
the interrupt attributes, which is x86 specific. Why does the msg data
need to contain the irq number? Here is my hypothetic explanation. The
device writes the MSI msg data to the specified MSI msg address. And
APIC uses the irq number in the msg data to generate appropriate
interrupt, which of course results in an appropriate ISR invoked. A
device having multiple MSI messages typically appends some information
of which MSI message to the msg data field. For example, if the system
(or OS) configures the MSI msg data as 0x5000, a device having 4 MSI
messages could write 0x5000, 0x5001, 0x5002, 0x5003 to differentiate
the MSI messages. However this cannot work with the APIC due to the
way how APIC asserts interrupts as I described above (if my
understanding is correct).

Hence my answer to the question is this is due to the x86 APIC. For
other architectures such as powerpc this is probably not a problem
since the interrupt controller is different. Am I correct?

TIA.
-Shawn.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ