From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Linux PCI <linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: Partial BAR Address Allocation
Date: Mon, 6 Mar 2017 12:04:39 +0100 [thread overview]
Message-ID: <20170306110439.GC27724@8bytes.org> (raw)
In-Reply-To: <20170222233944.GB4359-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
On Wed, Feb 22, 2017 at 05:39:44PM -0600, Bjorn Helgaas wrote:
> [+cc Joerg, iommu list]
>
> On Wed, Feb 22, 2017 at 03:44:53PM -0500, Sinan Kaya wrote:
> > On 2/22/2017 1:44 PM, Bjorn Helgaas wrote:
> > > There is no way for a driver to say "I only need this memory BAR and
> > > not the other ones." The reason is because the PCI_COMMAND_MEMORY bit
> > > enables *all* the memory BARs; there's no way to enable memory BARs
> > > selectively. If we enable memory BARs and one of them is unassigned,
> > > that unassigned BAR is enabled, and the device will respond at
> > > whatever address the register happens to contain, and that may cause
> > > conflicts.
Hmm, maybe I am missing something, but isn't this only a problem if the
'unassigned' BAR as an address configured that also falls into the
Bridge-Window of the parent bridge? Otherwise no requests should be
routed to the BAR anyway, right?
> > The problem is that according to PCI specification BAR addresses and
> > DMA addresses cannot overlap.
> >
> > From PCI-to-PCI Bridge Arch. spec.: "A bridge forwards PCI memory
> > transactions from its primary interface to its secondary interface
> > (downstream) if a memory address is in the range defined by the
> > Memory Base and Memory Limit registers (when the base is less than
> > or equal to the limit) as illustrated in Figure 4-3. Conversely, a
> > memory transaction on the secondary interface that is within this
> > address range will not be forwarded upstream to the primary
> > interface."
> >
> > To be specific, if your DMA address happens to be in
> > [0x80000000-0xffffffff] and root port's aperture includes this
> > range; the DMA will never make to the system memory.
If there is no translation by an IOMMU this shouldn't be a problem, as
long as the bridge windows don't overlap with system ram. With
translation the IOMMU driver has to take care of that, which they
usually do.
> Hmmm. I guess SWIOTLB assumes there's no address translation in the
> DMA direction, right? If there's no address translation in the PIO
> direction, PCI bus BAR addresses are identical to the CPU-side
> addresses. In that case, there's no conflict because we already have
> to assign BARs so they never look like a system memory address.
Yes, SWIOTLB assumes that IOVA == PA.
> But if there *is* address translation in the PIO direction, we can
> have conflicts because the bridge can translate CPU-side PIO accesses
> to arbitrary PCI bus addresses.
I am not aware of any hardware that does translation on the PIO space.
The IOMMUs I know of don't care about PIO at all.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Sinan Kaya <okaya@codeaurora.org>,
Linux PCI <linux-pci@vger.kernel.org>,
iommu@lists.linux-foundation.org
Subject: Re: Partial BAR Address Allocation
Date: Mon, 6 Mar 2017 12:04:39 +0100 [thread overview]
Message-ID: <20170306110439.GC27724@8bytes.org> (raw)
In-Reply-To: <20170222233944.GB4359@bhelgaas-glaptop.roam.corp.google.com>
On Wed, Feb 22, 2017 at 05:39:44PM -0600, Bjorn Helgaas wrote:
> [+cc Joerg, iommu list]
>
> On Wed, Feb 22, 2017 at 03:44:53PM -0500, Sinan Kaya wrote:
> > On 2/22/2017 1:44 PM, Bjorn Helgaas wrote:
> > > There is no way for a driver to say "I only need this memory BAR and
> > > not the other ones." The reason is because the PCI_COMMAND_MEMORY bit
> > > enables *all* the memory BARs; there's no way to enable memory BARs
> > > selectively. If we enable memory BARs and one of them is unassigned,
> > > that unassigned BAR is enabled, and the device will respond at
> > > whatever address the register happens to contain, and that may cause
> > > conflicts.
Hmm, maybe I am missing something, but isn't this only a problem if the
'unassigned' BAR as an address configured that also falls into the
Bridge-Window of the parent bridge? Otherwise no requests should be
routed to the BAR anyway, right?
> > The problem is that according to PCI specification BAR addresses and
> > DMA addresses cannot overlap.
> >
> > From PCI-to-PCI Bridge Arch. spec.: "A bridge forwards PCI memory
> > transactions from its primary interface to its secondary interface
> > (downstream) if a memory address is in the range defined by the
> > Memory Base and Memory Limit registers (when the base is less than
> > or equal to the limit) as illustrated in Figure 4-3. Conversely, a
> > memory transaction on the secondary interface that is within this
> > address range will not be forwarded upstream to the primary
> > interface."
> >
> > To be specific, if your DMA address happens to be in
> > [0x80000000-0xffffffff] and root port's aperture includes this
> > range; the DMA will never make to the system memory.
If there is no translation by an IOMMU this shouldn't be a problem, as
long as the bridge windows don't overlap with system ram. With
translation the IOMMU driver has to take care of that, which they
usually do.
> Hmmm. I guess SWIOTLB assumes there's no address translation in the
> DMA direction, right? If there's no address translation in the PIO
> direction, PCI bus BAR addresses are identical to the CPU-side
> addresses. In that case, there's no conflict because we already have
> to assign BARs so they never look like a system memory address.
Yes, SWIOTLB assumes that IOVA == PA.
> But if there *is* address translation in the PIO direction, we can
> have conflicts because the bridge can translate CPU-side PIO accesses
> to arbitrary PCI bus addresses.
I am not aware of any hardware that does translation on the PIO space.
The IOMMUs I know of don't care about PIO at all.
Joerg
next prev parent reply other threads:[~2017-03-06 11:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-22 18:03 Partial BAR Address Allocation Sinan Kaya
2017-02-22 18:44 ` Bjorn Helgaas
2017-02-22 20:44 ` Sinan Kaya
[not found] ` <43c1ff36-fc50-8ea4-02fe-7b1d573a1efd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-02-22 23:39 ` Bjorn Helgaas
2017-02-22 23:39 ` Bjorn Helgaas
2017-02-23 11:40 ` Robin Murphy
2017-02-23 13:54 ` Sinan Kaya
[not found] ` <20170222233944.GB4359-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2017-03-06 11:04 ` Joerg Roedel [this message]
2017-03-06 11:04 ` Joerg Roedel
[not found] ` <20170306110439.GC27724-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-03-08 15:42 ` Sinan Kaya
2017-03-08 15:42 ` Sinan Kaya
2017-03-10 20:14 ` Bjorn Helgaas
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=20170306110439.GC27724@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.