iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	llvm@lists.linux.dev, Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>, Tom Rix <trix@redhat.com>,
	Will Deacon <will@kernel.org>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Kevin Tian <kevin.tian@intel.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>
Subject: [PATCH v5 15/17] iommu: Allow IOMMU_RESV_DIRECT to work on ARM
Date: Thu, 11 May 2023 01:42:13 -0300	[thread overview]
Message-ID: <15-v5-1b99ae392328+44574-iommu_err_unwind_jgg@nvidia.com> (raw)
In-Reply-To: <0-v5-1b99ae392328+44574-iommu_err_unwind_jgg@nvidia.com>

For now several ARM drivers do not allow mappings to be created until a
domain is attached. This means they do not technically support
IOMMU_RESV_DIRECT as it requires the 1:1 maps to work continuously.

Currently if the platform requests these maps on ARM systems they are
silently ignored.

Work around this by trying again to establish the direct mappings after
the domain is attached if the pre-attach attempt failed.

In the long run the drivers will be fixed to fully setup domains when they
are created without waiting for attachment.

Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
 drivers/iommu/iommu.c | 33 +++++++++++++++++++++++++++++++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index cb1287d4d5dec7..a710e3b5d1e6ba 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2841,6 +2841,7 @@ static int iommu_setup_default_domain(struct iommu_group *group,
 	struct iommu_domain *old_dom = group->default_domain;
 	struct group_device *gdev;
 	struct iommu_domain *dom;
+	bool direct_failed;
 	int req_type;
 	int ret;
 
@@ -2874,8 +2875,15 @@ static int iommu_setup_default_domain(struct iommu_group *group,
 	 * mapped before their device is attached, in order to guarantee
 	 * continuity with any FW activity
 	 */
-	for_each_group_device(group, gdev)
-		iommu_create_device_direct_mappings(dom, gdev->dev);
+	direct_failed = false;
+	for_each_group_device(group, gdev) {
+		if (iommu_create_device_direct_mappings(dom, gdev->dev)) {
+			direct_failed = true;
+			dev_warn_once(
+				gdev->dev->iommu->iommu_dev->dev,
+				"IOMMU driver was not able to establish FW requested direct mapping.");
+		}
+	}
 
 	/* We must set default_domain early for __iommu_device_set_domain */
 	group->default_domain = dom;
@@ -2899,6 +2907,27 @@ static int iommu_setup_default_domain(struct iommu_group *group,
 		}
 	}
 
+	/*
+	 * Drivers are supposed to allow mappings to be installed in a domain
+	 * before device attachment, but some don't. Hack around this defect by
+	 * trying again after attaching. If this happens it means the device
+	 * will not continuously have the IOMMU_RESV_DIRECT map.
+	 */
+	if (direct_failed) {
+		for_each_group_device(group, gdev) {
+			ret = iommu_create_device_direct_mappings(dom, gdev->dev);
+			if (ret)
+				goto err_restore;
+		}
+	}
+
+err_restore:
+	if (old_dom) {
+		__iommu_group_set_domain_internal(
+			group, old_dom, IOMMU_SET_DOMAIN_MUST_SUCCEED);
+		iommu_domain_free(dom);
+		old_dom = NULL;
+	}
 out_free:
 	if (old_dom)
 		iommu_domain_free(old_dom);
-- 
2.40.1


  parent reply	other threads:[~2023-05-11  4:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11  4:41 [PATCH v5 00/17] Consolidate the error handling around device attachment Jason Gunthorpe
2023-05-11  4:41 ` [PATCH v5 01/17] iommu: Replace iommu_group_device_count() with list_count_nodes() Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 02/17] iommu: Add for_each_group_device() Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 03/17] iommu: Make __iommu_group_set_domain() handle error unwind Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 04/17] iommu: Use __iommu_group_set_domain() for __iommu_attach_group() Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 05/17] iommu: Use __iommu_group_set_domain() in iommu_change_dev_def_domain() Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 06/17] iommu: Replace __iommu_group_dma_first_attach() with set_domain Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 07/17] iommu: Remove iommu_group_do_dma_first_attach() from iommu_group_add_device() Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 08/17] iommu: Replace iommu_group_do_dma_first_attach with __iommu_device_set_domain Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 09/17] iommu: Fix iommu_probe_device() to attach the right domain Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 10/17] iommu: Do iommu_group_create_direct_mappings() before attach Jason Gunthorpe
2023-06-05  7:09   ` Ricardo Cañuelo
2023-06-05 13:47     ` Jason Gunthorpe
2023-06-05 14:00       ` Robin Murphy
2023-06-05 14:11         ` Jason Gunthorpe
2023-06-06  5:33         ` Ricardo Cañuelo
2023-05-11  4:42 ` [PATCH v5 11/17] iommu: Remove the assignment of group->domain during default domain alloc Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 12/17] iommu: Consolidate the code to calculate the target default domain type Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 13/17] iommu: Revise iommu_group_alloc_default_domain() Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 14/17] iommu: Consolidate the default_domain setup to one function Jason Gunthorpe
2023-05-11  4:42 ` Jason Gunthorpe [this message]
2023-05-11  4:42 ` [PATCH v5 16/17] iommu: Remove __iommu_group_for_each_dev() Jason Gunthorpe
2023-05-11  4:42 ` [PATCH v5 17/17] iommu: Tidy the control flow in iommu_group_store_type() Jason Gunthorpe
2023-05-23  6:16 ` [PATCH v5 00/17] Consolidate the error handling around device attachment Joerg Roedel

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=15-v5-1b99ae392328+44574-iommu_err_unwind_jgg@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolinc@nvidia.com \
    --cc=ojeda@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=trix@redhat.com \
    --cc=will@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).