linux-kernel - Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

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]

Message-ID: <Pine.LNX.4.64.0611141935390.3349@woody.osdl.org>
Date:	Tue, 14 Nov 2006 19:54:38 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	David Miller <davem@...emloft.net>
cc:	jeff@...zik.org, linux-kernel@...r.kernel.org, tiwai@...e.de
Subject: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

On Tue, 14 Nov 2006, David Miller wrote:
> 
> > Yours was still an example of "nice". And it had absolutely nothing
> > to do with the _PROBLEM_.
> 
> Understood.

Btw, before somebody thinks I hate MSI - I'd absolutely _love_ for it to 
work, because I think MSI has the potential of getting rid of a lot of irq 
routing problems.

And that's more than just a "nice" - we've obviously had issues with 
machines not working right because we didn't get the magic PIRQ tables or 
ACPI crud right. 

So I'd actually be thrilled if we could use MSI more. (And here, "MSI" 
should be considered to also include "MSI-X" etc - please, no language 
lawyering).

> Given current experience maybe white-lists are in fact the way
> to go.

The thing that worries me is that I can well believe that the Intel NB/SB 
combination gets MSI 100% correct, and I'd love to whitelist it.

HOWEVER - that's only true on systems with no other PCI bridges. Even if 
you have an Intel NB/SB, what about other bridges in that same system, and 
the devices behind them? 

Now, I think that a MSI thing should look like a PCI write to a magic 
address (I'm really not very up on it, so correct me if I'm wrong), and 
thus maybe bridges are bound to get it right, and the only thing we really 
need to worry about is the host bridge. Maybe. In that case, it might be 
sensible to have a host-bridge white-table, and if we know all Intel 
bridges that claim to support MSI do so correctly, then maybe we can just 
say "ok, always enable it for Intel host bridges".

But right now I'm not convinced we really know what all goes wrong. Maybe 
it's just broken NVidia and AMD bridges. But maybe it's also individual 
devices that continue to (for example) raise _both_ the legacy IRQ line 
_and_ send an MSI request.

Maybe even Intel host bridges have all the same troubles with that, and 
the reason we haven't seen it is that _usually_ an Intel host bridge goes 
together with certain Intel MSI-capable chips (ie e1000, Intel HDA etc). 
So for all we know, it's not necessarily the Intel host bridge that is the 
magic thing to make things work, it could be something that just has a 
high _correlation_ with an Intel host bridge.

So call me a nervous nellie. 

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