All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Yijing Wang <wangyijing@huawei.com>
Cc: wdavis@nvidia.com, Joerg Roedel <joro@8bytes.org>,
	"open list:INTEL IOMMU (VT-d)" <iommu@lists.linux-foundation.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	tripperda@nvidia.com, jhubbard@nvidia.com,
	Jerome Glisse <jglisse@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH 0/6] IOMMU/DMA map_resource support for peer-to-peer
Date: Thu, 7 May 2015 08:13:04 -0500	[thread overview]
Message-ID: <CAErSpo6xp5kM57PX9RkXKr5MM4BQM7-uXPtvCBL8=9Br8FYLdA@mail.gmail.com> (raw)
In-Reply-To: <554AC48A.2030209@huawei.com>

On Wed, May 6, 2015 at 8:48 PM, Yijing Wang <wangyijing@huawei.com> wrote:
> On 2015/5/7 6:18, Bjorn Helgaas wrote:
>> [+cc Yijing, Dave J, Dave M, Alex]
>>
>> On Fri, May 01, 2015 at 01:32:12PM -0500, wdavis@nvidia.com wrote:
>>> From: Will Davis <wdavis@nvidia.com>
>>>
>>> Hi,
>>>
>>> This patch series adds DMA APIs to map and unmap a struct resource to and from
>>> a PCI device's IOVA domain, and implements the AMD, Intel, and nommu versions
>>> of these interfaces.
>>>
>>> This solves a long-standing problem with the existing DMA-remapping interfaces,
>>> which require that a struct page be given for the region to be mapped into a
>>> device's IOVA domain. This requirement cannot support peer device BAR ranges,
>>> for which no struct pages exist.
>>> ...

>> I think we currently assume there's no peer-to-peer traffic.
>>
>> I don't know whether changing that will break anything, but I'm concerned
>> about these:
>>
>>   - PCIe MPS configuration (see pcie_bus_configure_settings()).
>
> I think it should be ok for PCIe MPS configuration, PCIE_BUS_PEER2PEER force every
> device's MPS to 128B, what its concern is the TLP payload size. In this series, it
> seems to only map a iova for device bar region.

MPS configuration makes assumptions about whether there will be any
peer-to-peer traffic.  If there will be none, MPS can be configured
more aggressively.

I don't think Linux has any way to detect whether a driver is doing
peer-to-peer, and there's no way to prevent a driver from doing it.
We're stuck with requiring the user to specify boot options
("pci=pcie_bus_safe", "pci=pcie_bus_perf", "pci=pcie_bus_peer2peer",
etc.) that tell the PCI core what the user expects to happen.

This is a terrible user experience.  The user has no way to tell what
drivers are going to do.  If he specifies the wrong thing, e.g.,
"assume no peer-to-peer traffic," and then loads a driver that does
peer-to-peer, the kernel will configure MPS aggressively and when the
device does a peer-to-peer transfer, it may cause a Malformed TLP
error.

Bjorn

  reply	other threads:[~2015-05-07 13:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01 18:32 [PATCH 0/6] IOMMU/DMA map_resource support for peer-to-peer wdavis
2015-05-01 18:32 ` wdavis-DDmLM1+adcrQT0dZR+AlfA
2015-05-01 18:32 ` [PATCH 1/6] dma-debug: add checking for map/unmap_resource wdavis
2015-05-01 18:32 ` [PATCH 2/6] DMA-API: Introduce dma_(un)map_resource wdavis
2015-05-07 15:09   ` Bjorn Helgaas
2015-05-07 16:10     ` William Davis
2015-05-01 18:32 ` [PATCH 3/6] dma-mapping: pci: add pci_(un)map_resource wdavis
2015-05-07 15:19   ` Bjorn Helgaas
2015-05-07 15:19     ` Bjorn Helgaas
2015-05-11 14:30     ` Konrad Rzeszutek Wilk
2015-05-11 14:30       ` Konrad Rzeszutek Wilk
2015-05-11 15:27       ` Bjorn Helgaas
2015-05-01 18:32 ` [PATCH 4/6] iommu/amd: Implement (un)map_resource wdavis
2015-05-01 18:32 ` [PATCH 5/6] iommu/vt-d: implement (un)map_resource wdavis
2015-05-01 18:32 ` [PATCH 6/6] x86: add pci-nommu implementation of map_resource wdavis
2015-05-07 15:08   ` Bjorn Helgaas
2015-05-07 16:07     ` William Davis
2015-05-06 22:18 ` [PATCH 0/6] IOMMU/DMA map_resource support for peer-to-peer Bjorn Helgaas
2015-05-06 22:30   ` Alex Williamson
2015-05-07  1:48   ` Yijing Wang
2015-05-07  1:48     ` Yijing Wang
2015-05-07 13:13     ` Bjorn Helgaas [this message]
2015-05-07 16:23       ` William Davis
2015-05-07 16:23         ` William Davis
2015-05-07 17:16         ` Bjorn Helgaas
2015-05-07 18:11           ` Jerome Glisse
2015-05-11 19:21             ` Don Dutile
2015-05-11 19:21               ` Don Dutile
2015-05-08 20:21 ` Konrad Rzeszutek Wilk
2015-05-08 20:46   ` Mark Hounschell
2015-05-11 14:32     ` Konrad Rzeszutek Wilk
2015-05-11 14:32       ` Konrad Rzeszutek Wilk
2015-05-11 20:05     ` William Davis
2015-05-11 19:49   ` William Davis

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='CAErSpo6xp5kM57PX9RkXKr5MM4BQM7-uXPtvCBL8=9Br8FYLdA@mail.gmail.com' \
    --to=bhelgaas@google.com \
    --cc=alex.williamson@redhat.com \
    --cc=dave.jiang@intel.com \
    --cc=davem@davemloft.net \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jglisse@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=tripperda@nvidia.com \
    --cc=wangyijing@huawei.com \
    --cc=wdavis@nvidia.com \
    /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.