From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
To: Robert Hancock <hancockr@shaw.ca>
Cc: benh@kernel.crashing.org, linux-pci@atrey.karlin.mff.cuni.cz,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Possible issue with dangling PCI BARs
Date: Thu, 13 Dec 2007 12:04:03 +0300 [thread overview]
Message-ID: <20071213120403.B21124@jurassic.park.msu.ru> (raw)
In-Reply-To: <4760B37E.3010002@shaw.ca>; from hancockr@shaw.ca on Wed, Dec 12, 2007 at 10:22:22PM -0600
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.
next prev parent reply other threads:[~2007-12-13 9:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.YfTvVN5C3e6zwXPW5biWgeZ9XXc@ifi.uio.no>
[not found] ` <fa.EhUqlM3V3y3HCcQkLBLSEKTJxBs@ifi.uio.no>
[not found] ` <fa.4FjaYKIciOijtgO+0DDrMkrLjv0@ifi.uio.no>
2007-12-13 4:22 ` Robert Hancock
2007-12-13 5:26 ` Benjamin Herrenschmidt
2007-12-13 9:14 ` Ivan Kokshaysky
2007-12-13 9:29 ` Benjamin Herrenschmidt
2007-12-13 9:04 ` Ivan Kokshaysky [this message]
2007-12-13 10:24 ` Alan Cox
2007-12-13 11:17 ` Benjamin Herrenschmidt
2007-12-13 11:20 ` Benjamin Herrenschmidt
2007-12-13 20:04 ` Jesse Barnes
2007-12-13 20:51 ` Benjamin Herrenschmidt
2007-12-13 21:12 ` Ivan Kokshaysky
2007-12-13 23:09 ` Benjamin Herrenschmidt
2007-12-13 21:02 ` Ivan Kokshaysky
2007-12-13 13:27 ` Alan Cox
2007-12-13 3:00 Benjamin Herrenschmidt
2007-12-13 3:04 ` Benjamin Herrenschmidt
2007-12-13 3:40 ` Benjamin Herrenschmidt
2007-12-14 11:52 ` Jon Masters
2007-12-14 22:11 ` Benjamin Herrenschmidt
2007-12-15 2:18 ` Jon Masters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071213120403.B21124@jurassic.park.msu.ru \
--to=ink@jurassic.park.msu.ru \
--cc=benh@kernel.crashing.org \
--cc=hancockr@shaw.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®