From: Bjorn Helgaas <bhelgaas@google.com>
To: Will Davis <wdavis@nvidia.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Joerg Roedel <joro@8bytes.org>,
iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
Konrad Wilk <konrad.wilk@oracle.com>,
Mark Hounschell <markh@compro.net>,
"David S. Miller" <davem@davemloft.net>,
Jonathan Corbet <corbet@lwn.net>,
Terence Ripperda <tripperda@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
Jerome Glisse <jglisse@redhat.com>
Subject: Re: [PATCH v4 09/12] iommu/vt-d: implement (un)map_peer_resource
Date: Mon, 10 Aug 2015 12:02:17 -0500 [thread overview]
Message-ID: <20150810170217.GB32452@google.com> (raw)
In-Reply-To: <1437601197-6481-10-git-send-email-wdavis@nvidia.com>
On Wed, Jul 22, 2015 at 04:39:54PM -0500, Will Davis wrote:
> Implement 'map_peer_resource' for the Intel IOMMU driver. Simply translate
> the resource to a physical address and route it to the same handlers used
> by the 'map_page' API.
>
> This allows a device to map another's resource, to enable peer-to-peer
> transactions.
>
> These functions are guarded behind CONFIG_HAS_DMA_P2P, since the
> dma_map_ops members are as well.
>
> Signed-off-by: Will Davis <wdavis@nvidia.com>
> Reviewed-by: Terence Ripperda <tripperda@nvidia.com>
> Reviewed-by: John Hubbard <jhubbard@nvidia.com>
> ---
> drivers/iommu/intel-iommu.c | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index a98a7b2..66b371c 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -3544,6 +3544,40 @@ static void intel_unmap_page(struct device *dev, dma_addr_t dev_addr,
> intel_unmap(dev, dev_addr);
> }
>
> +#ifdef CONFIG_HAS_DMA_P2P
> +static dma_peer_addr_t intel_map_peer_resource(struct device *dev,
> + struct device *peer,
> + struct resource *res,
> + unsigned long offset,
> + size_t size,
> + enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct pci_dev *ppeer = to_pci_dev(peer);
You got "struct device" pointers, so they might not be PCI devices. You
should probably return an error if one is not PCI.
> + struct pci_host_bridge *hbdev = pci_find_host_bridge(pdev->bus);
> + struct pci_host_bridge *hbpeer = pci_find_host_bridge(ppeer->bus);
> +
> + /*
> + * Disallow the peer-to-peer mapping if the devices do not share a host
> + * bridge.
> + */
> + if (hbdev != hbpeer)
> + return 0;
I think the only thing guaranteed by the spec is peer-to-peer between
devices in the same hierarchy, where the hierarchy is rooted at a PCIe Root
Port or a conventional PCI host bridge. I don't remember anything about
transactions between Root Ports or conventional PCI host bridges.
If there is some language in the spec about those transactions, a citation
here would be nice.
This decision might be better made by a PCI interface. This same basic
logic is repeated here, in the AMD equivalent, and in the x86 code, and I
suspect it will end up being a little more complicated for the reasons
above.
> +
> + return __intel_map_single(dev, res->start + offset, size,
> + dir, *dev->dma_mask);
> +}
> +
> +static void intel_unmap_peer_resource(struct device *dev,
> + dma_peer_addr_t dev_addr,
> + size_t size, enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + intel_unmap(dev, dev_addr);
> +}
> +#endif
> +
> static void *intel_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flags,
> struct dma_attrs *attrs)
> @@ -3700,6 +3734,10 @@ struct dma_map_ops intel_dma_ops = {
> .unmap_sg = intel_unmap_sg,
> .map_page = intel_map_page,
> .unmap_page = intel_unmap_page,
> +#ifdef CONFIG_HAS_DMA_P2P
> + .map_peer_resource = intel_map_peer_resource,
> + .unmap_peer_resource = intel_unmap_peer_resource,
> +#endif
> .mapping_error = intel_mapping_error,
> };
>
> --
> 2.4.6
>
next prev parent reply other threads:[~2015-08-10 17:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 21:39 [PATCH v4 00/12] DMA-API/PCI map_peer_resource support for peer-to-peer Will Davis
2015-07-22 21:39 ` Will Davis
[not found] ` <1437601197-6481-1-git-send-email-wdavis-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-07-22 21:39 ` [PATCH v4 01/12] lib/Kconfig: add HAS_DMA_P2P for peer-to-peer support Will Davis
2015-07-22 21:39 ` Will Davis
2015-07-22 21:39 ` [PATCH v4 02/12] linux/types.h: Add dma_peer_addr_t type Will Davis
2015-07-22 21:39 ` Will Davis
2015-07-22 21:39 ` [PATCH v4 04/12] DMA-API: Introduce dma_(un)map_peer_resource Will Davis
2015-07-22 21:39 ` Will Davis
2015-07-22 21:39 ` [PATCH v4 05/12] dma-mapping: pci: add pci_(un)map_peer_resource Will Davis
2015-07-22 21:39 ` Will Davis
2015-07-22 21:39 ` [PATCH v4 03/12] dma-debug: add checking for map/unmap_peer_resource Will Davis
2015-07-22 21:39 ` Will Davis
2015-07-22 21:39 ` [PATCH v4 06/12] DMA-API: Add peer resource mapping documentation Will Davis
2015-07-22 21:39 ` Will Davis
2015-07-22 21:39 ` [PATCH v4 07/12] pci: expose pci_find_host_bridge() Will Davis
2015-07-22 21:39 ` Will Davis
2015-08-10 17:08 ` Bjorn Helgaas
2015-07-22 21:39 ` [PATCH v4 08/12] iommu/amd: Implement (un)map_peer_resource Will Davis
2015-07-22 21:39 ` Will Davis
2015-07-22 21:39 ` [PATCH v4 09/12] iommu/vt-d: implement (un)map_peer_resource Will Davis
2015-07-22 21:39 ` Will Davis
2015-08-10 17:02 ` Bjorn Helgaas [this message]
[not found] ` <20150810170217.GB32452-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-08-10 18:29 ` William Davis
2015-08-10 18:29 ` William Davis
2015-07-22 21:39 ` [PATCH v4 10/12] pci: add pci_find_common_upstream_dev() Will Davis
2015-07-22 21:39 ` Will Davis
2015-08-10 16:51 ` Bjorn Helgaas
2015-07-22 21:39 ` [PATCH v4 11/12] x86: add pci-nommu implementation of map_peer_resource Will Davis
2015-07-22 21:39 ` Will Davis
2015-07-22 21:39 ` [PATCH v4 12/12] x86: declare support for DMA P2P Will Davis
2015-07-22 21:39 ` Will Davis
2015-08-10 15:52 ` [PATCH v4 00/12] DMA-API/PCI map_peer_resource support for peer-to-peer Will Davis
2015-08-10 15:52 ` Will 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=20150810170217.GB32452@google.com \
--to=bhelgaas@google.com \
--cc=alex.williamson@redhat.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=iommu@lists.linux-foundation.org \
--cc=jglisse@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=joro@8bytes.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-pci@vger.kernel.org \
--cc=markh@compro.net \
--cc=tripperda@nvidia.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.