linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org
Cc: bhelgaas@google.com, Joerg Roedel <joro@8bytes.org>,
	acooks@gmail.com, linux-kernel@vger.kernel.org
Subject: [PATCH 07/13] iommu/amd: Update to use PCI DMA aliases
Date: Thu, 01 May 2014 10:27:48 -0600	[thread overview]
Message-ID: <20140501162748.17512.4466.stgit@bling.home> (raw)
In-Reply-To: <20140501160128.17512.23609.stgit@bling.home>

AMD-Vi already has a concept of an alias provided via the IVRS table.
This alias only handles topology based aliases, such as PCIe-to-PCI
bridges.  When such an alias is present, we continue to use it.  When
a platform alias is not present, we can now add a check of the device
dma_func_alias to create our own.  Note that the current code can
only handle a single alias of a device, and we don't attempt to change
that here.  It would only become a factor for the requester ID seen by
the IOMMU if PCI-X were involved anway.

Since the alias is now potentially device specific rather than the
topology based alias provided by the platform, we need to clear it
when the device goes away.

With the DMA alias and isolation infrastructure now in PCI-core, we
could opt to ignore IVRS provided aliases.  We now do this for IOMMU
groups.  However, for this more common use case, the "don't fix what
isn't broken" mantra seems like the safer route.

This should allow AMD-Vi to work with devices like Marvell and Ricoh
with DMA function alias quirks.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
---
 drivers/iommu/amd_iommu.c |   27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 3d58de4..4621692 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -294,6 +294,7 @@ static int iommu_init_device(struct device *dev)
 	struct pci_dev *pdev = to_pci_dev(dev);
 	struct iommu_dev_data *dev_data;
 	u16 alias;
+	u8 func_alias;
 	int ret;
 
 	if (dev->archdata.iommu)
@@ -304,6 +305,19 @@ static int iommu_init_device(struct device *dev)
 		return -ENOMEM;
 
 	alias = amd_iommu_alias_table[dev_data->devid];
+
+	/*
+	 * If there is no platform provided alias (topology-based) check
+	 * if we have a device quirk based alias.
+	 */
+	func_alias = pdev->dma_func_alias & ~(1 << PCI_SLOT(pdev->devfn));
+	if (func_alias && alias == dev_data->devid) {
+		WARN_ON(hweight8(func_alias) > 1);
+		alias = PCI_DEVID(pdev->bus->number,
+				  PCI_DEVFN(PCI_SLOT(pdev->devfn),
+					    ffs(func_alias) - 1));
+	}
+
 	if (alias != dev_data->devid) {
 		struct iommu_dev_data *alias_data;
 
@@ -351,12 +365,19 @@ static void iommu_ignore_device(struct device *dev)
 
 static void iommu_uninit_device(struct device *dev)
 {
+	struct iommu_dev_data *dev_data = search_dev_data(get_device_id(dev));
+
+	if (!dev_data)
+		return;
+
 	iommu_group_remove_device(dev);
 
+	/* Unlink from alias, it may change if another device is re-plugged */
+	dev_data->alias_data = NULL;
+
 	/*
-	 * Nothing to do here - we keep dev_data around for unplugged devices
-	 * and reuse it when the device is re-plugged - not doing so would
-	 * introduce a ton of races.
+	 * We keep dev_data around for unplugged devices and reuse it when the
+	 * device is re-plugged - not doing so would introduce a ton of races.
 	 */
 }
 


  parent reply	other threads:[~2014-05-01 16:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01 16:27 [PATCH 00/13] PCI/iommu: Fix DMA alias problems Alex Williamson
2014-05-01 16:27 ` [PATCH 01/13] PCI: Add DMA alias iterator Alex Williamson
2014-05-01 16:27 ` [PATCH 02/13] PCI: quirk pci_for_each_dma_alias() Alex Williamson
2014-05-01 16:27 ` [PATCH 03/13] PCI: quirk dma_func_alias for Ricoh devices Alex Williamson
2014-05-03  2:29   ` Andrew Cooks
2014-05-03  5:15     ` Alex Williamson
2014-05-10  4:46       ` Andrew Cooks
2014-05-10  5:19         ` Alex Williamson
2014-05-01 16:27 ` [PATCH 04/13] PCI: quirk dma_func_alias for Marvell devices Alex Williamson
2014-05-01 16:27 ` [PATCH 05/13] PCI: Consolidate isolation domain code Alex Williamson
2014-05-01 16:27 ` [PATCH 06/13] iommu/amd: Use pci_find_dma_isolation_root() for IOMMU groups Alex Williamson
2014-05-01 16:27 ` Alex Williamson [this message]
2014-05-01 16:27 ` [PATCH 08/13] iommu/intel: " Alex Williamson
2014-05-01 16:28 ` [PATCH 09/13] iommu/intel: Update to use PCI DMA aliases Alex Williamson
2014-05-01 16:28 ` [PATCH 10/13] iommu/fsl: Use pci_find_dma_isolation_root() for IOMMU groups Alex Williamson
2014-05-01 16:28 ` [PATCH 11/13] iommu: Remove pci.h Alex Williamson
2014-05-01 16:28 ` [PATCH 12/13] PCI: Remove pci_find_upstream_pcie_bridge() Alex Williamson
2014-05-01 16:28 ` [PATCH 13/13] PCI: Remove pci_get_dma_source() Alex Williamson

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=20140501162748.17512.4466.stgit@bling.home \
    --to=alex.williamson@redhat.com \
    --cc=acooks@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).