Re: Possible issue with dangling PCI BARs

[Ivan Kokshaysky <ink@jurassic.park.msu.ru>]

On Wed, Dec 12, 2007 at 10:22:22PM -0600, Robert Hancock wrote:
> For the case where you say "I want to enable decoding for this MMIO BAR, 
> but not that one", though, I don't see an obvious way to provide that 
> guarantee with certainty. Normally, one would expect that if a BAR is 
> mapped safely outside the decode window of a PCI bridge it's behind, 
> that it won't ever see the requests and can't respond to them. However, 
> the Intel chipset MMCONFIG overlap fiasco appears to show that this is 
> not always the case and in some cases the device can see and respond to 
> requests outside of the bridge's decode window (with higher decode 
> priority than the MMCONFIG aperture, even)..

>From my reading of Intel specs, these priority decode rules apply only
to legacy VGA aperture (which doesn't have a BAR anyway) - that's why you
cannot have both internal and external VGA working together on these
chipsets. But for any normal BAR classic PCI bridge decode still works
as expected.

However, mapping a BAR outside the decode window of a PCI bridge
can be dangerous for another reason - it could clash with DMA from
a sibling device. Either with DMA to system RAM, if you put that BAR
below the parent bridge window, or with MSI, if you put it above...

So disabling memory or IO decode in a command register seems to be
the only safe option. This depends on architecture, though.

Ivan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/