> 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.
Yes, an MSI message really is just a PCI write cycle (which is why it
obeys all the PCI ordering as DaveM pointed out, and also can travel
on different PCIe VCs, etc). So it's hard to see how a bridge could
mess it up without screwing up lots of other stuff. The big thing is
the host bridge that has to turn the PCI write into an interrupt, and
that's where all the chipset problems that I know of are.
But on the other hand I don't think we have much experience with
MSI-capable devices below multiple levels of bridges, so you're right,
there is an unknown risk here.
> 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.
Well, since we now require drivers to "opt in" to MSI, I'm not
convinced that broken devices are a huge issue. We can take things
case-by-case and, obviously, if some random subset of devices are
broken, then clearly the driver should be really careful about
enabling MSI. But usually there's something like a device ID,
revision, FW version, etc. that we can test.
> together with certain Intel MSI-capable chips (ie e1000, Intel HDA etc).
Just for the record -- many e1000 chips that have an MSI capability in
their PCI config actually do not have working MSI. Hence the
if (adapter->hw.mac_type > e1000_82547_rev_2) {
adapter->have_msi = TRUE;
in the e1000 driver I guess.
BTW, at the end of the day I agree with the "MSI off by default"
policy, especially for the sound driver where the only realy gain is
saving IRQ routing hassles as you said. Even for the mthca InfiniBand
driver, where MSI-X with multiple vectors is a huge performance win, I
still have the user explicitly enable it.
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
