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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
