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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1163643776.5940.338.camel@localhost.localdomain>
Date:	Thu, 16 Nov 2006 13:22:56 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	David Miller <davem@...emloft.net>, jeff@...zik.org,
	linux-kernel@...r.kernel.org, tiwai@...e.de
Subject: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

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

Well... MSIs are just normal stores as far as PCI is concerned. Thus, if
you have P2P bridges in your system and they can't get store ordering
right, I think you have a much bigger problem than getting MSIs wrong.

I think the problem is mostly with host bridges doing crappy stuffs like
decoding MSIs up front and sending them to the CPU out of order or
HT<->PCI (or some home made backbone <-> PCI) bridges where MSIs gets
turned into something else with potentially ordering breakage at the
transformation point or the upstream bus.

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

Host bridges or something <-> PCI (something = HT, or some of the fancy
NB<->SB links other vendors use).

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

Yeah, well, the later can be solved in software by masking the LSI when
MSI is enabled for a device.

Cheers,
Ben.

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