linux-kernel - Re: MSI changes in .28

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:	Fri, 05 Dec 2008 09:49:41 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Frans Pop <elendil@...net.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>, rjw@...k.pl,
	greg@...ah.com, jbarnes@...tuousgeek.org, lenb@...nel.org,
	linux-kernel@...r.kernel.org, tiwai@...e.de,
	akpm@...ux-foundation.org, ink@...assic.park.msu.ru,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: MSI changes in .28

Ingo Molnar wrote:
> 
> The MSI IRQ number is a pure software detail that was already non-stable 
> due to device detection ordering, etc. It's counted back from NR_IRQS, 
> and the sizing of NR_IRQS changed (upwards) in 2.6.28 - that's what you 
> see.
> 
> The fact that MSI numbers goes back from NR_IRQs i consider a (minor) 
> misbehavior: it should not count down but should count up - and it should 
> not go to unreasonably high numbers if possible - that is confusing to 
> users when the sizing of NR_IRQS changes to to a higher NR_CPUS for 
> example.
> 
> A better (because more human-compatible) numbering scheme is to start 
> counting upwards from the high end of physical interrupt lines. We've 
> done that in the for-.29 sparseirq tree - there we'll start counting from 
> 256 upwards in essence. (the first 256 IRQs are GSI interrupts)
> 

Although it's kind of broken to limit the number of GSI interrupts to
256, at least for HyperTransport systems where you can have MSIs that
look like IOAPICs (although discovered using a slightly different
mechanism.)

This also means, at least in theory, that IOAPICs could be discovered at
runtime!

> Maybe it should be counted starting at 1000? That might be an even more 
> human-friendly numbering scheme.

Personally I think we should just fix the legacy PIC and southbridge
IOAPIC at zero, and let everything grow up from there.  We'll assign
IOAPIC numbers first just by virtue of them being discovered first, but
I don't really see a huge need to partition the space.

Assigning them numbers starting with 1000 does stand out, of course;
however, if we do that then we really need to make sure we don't run
into ugly surprises on HT systems.  On the other hand, perhaps none will
ever be built, since newer HT silicon is likely to use MSI-X rather than
MSI-HT just for compatiblity.

	-hpa

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