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, 5 Dec 2008 13:20:06 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frans Pop <elendil@...net.nl>
Cc:	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,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: MSI changes in .28


* Frans Pop <elendil@...net.nl> wrote:

> On Tuesday 02 December 2008, Linus Torvalds wrote:
> > So, it looks like you have MSI enabled in -rc6, and not in -rc3.
> 
> I've just compared dmesg for my *desktop* and there I see the following 
> between 2.6.28-rc6 and current 2.6.28-rc7:
> 
>  pcieport-driver 0000:00:1c.0: setting latency timer to 64
>  pcieport-driver 0000:00:1c.0: found MSI capability
> -pcieport-driver 0000:00:1c.0: irq 47 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.0: irq 511 for MSI/MSI-X
>  pci_express 0000:00:1c.0:pcie00: allocate port service
>  pci_express 0000:00:1c.0:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.2: setting latency timer to 64
>  pcieport-driver 0000:00:1c.2: found MSI capability
> -pcieport-driver 0000:00:1c.2: irq 46 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.2: irq 510 for MSI/MSI-X
>  pci_express 0000:00:1c.2:pcie00: allocate port service
>  pci_express 0000:00:1c.2:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.3: setting latency timer to 64
>  pcieport-driver 0000:00:1c.3: found MSI capability
> -pcieport-driver 0000:00:1c.3: irq 45 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.3: irq 509 for MSI/MSI-X
>  pci_express 0000:00:1c.3:pcie00: allocate port service
>  pci_express 0000:00:1c.3:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.4: setting latency timer to 64
>  pcieport-driver 0000:00:1c.4: found MSI capability
> -pcieport-driver 0000:00:1c.4: irq 44 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.4: irq 508 for MSI/MSI-X
>  pci_express 0000:00:1c.4:pcie00: allocate port service
>  pci_express 0000:00:1c.4:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.5: setting latency timer to 64
>  pcieport-driver 0000:00:1c.5: found MSI capability
> -pcieport-driver 0000:00:1c.5: irq 43 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.5: irq 507 for MSI/MSI-X
> [...]
>  ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> -ahci 0000:00:1f.2: irq 42 for MSI/MSI-X
> +ahci 0000:00:1f.2: irq 506 for MSI/MSI-X
>  ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
> [...]
>  e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>  e1000e 0000:01:00.0: setting latency timer to 64
> -e1000e 0000:01:00.0: irq 41 for MSI/MSI-X
> +e1000e 0000:01:00.0: irq 505 for MSI/MSI-X
> 
> I.e. very similar to the change between rc-3 and rc-7 you commented on 
> for my notebook.
> 
> Is this really MSI being (not) enabled, or just it using much higher 
> IRQ numbers?

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)

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

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