Re: MSI changes in .28

["H. Peter Anvin" <hpa@zytor.com>]

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