All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>, Tom Murphy <murphyt7@tcd.ie>,
	David Woodhouse <dwmw2@infradead.org>,
	Christoph Hellwig <hch@infradead.org>
Cc: Ashok Raj <ashok.raj@intel.com>,
	Intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org,
	Lu Baolu <baolu.lu@linux.intel.com>
Subject: [Intel-gfx] [PATCH v4 5/7] iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
Date: Sun, 27 Sep 2020 14:34:35 +0800	[thread overview]
Message-ID: <20200927063437.13988-6-baolu.lu@linux.intel.com> (raw)
In-Reply-To: <20200927063437.13988-1-baolu.lu@linux.intel.com>

The iommu-dma constrains IOVA allocation based on the domain geometry
that the driver reports. Update domain geometry everytime a domain is
attached to or detached from a device.

Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
 drivers/iommu/intel/iommu.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index fdd514c8b2d4..7d3c73d1e498 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -67,8 +67,8 @@
 #define MAX_AGAW_WIDTH 64
 #define MAX_AGAW_PFN_WIDTH	(MAX_AGAW_WIDTH - VTD_PAGE_SHIFT)
 
-#define __DOMAIN_MAX_PFN(gaw)  ((((uint64_t)1) << (gaw-VTD_PAGE_SHIFT)) - 1)
-#define __DOMAIN_MAX_ADDR(gaw) ((((uint64_t)1) << gaw) - 1)
+#define __DOMAIN_MAX_PFN(gaw)  ((((uint64_t)1) << ((gaw) - VTD_PAGE_SHIFT)) - 1)
+#define __DOMAIN_MAX_ADDR(gaw) ((((uint64_t)1) << (gaw)) - 1)
 
 /* We limit DOMAIN_MAX_PFN to fit in an unsigned long, and DOMAIN_MAX_ADDR
    to match. That way, we can use 'unsigned long' for PFNs with impunity. */
@@ -739,6 +739,18 @@ static void domain_update_iommu_cap(struct dmar_domain *domain)
 	 */
 	if (domain->nid == NUMA_NO_NODE)
 		domain->nid = domain_update_device_node(domain);
+
+	/*
+	 * First-level translation restricts the input-address to a
+	 * canonical address (i.e., address bits 63:N have the same
+	 * value as address bit [N-1], where N is 48-bits with 4-level
+	 * paging and 57-bits with 5-level paging). Hence, skip bit
+	 * [N-1].
+	 */
+	if (domain_use_first_level(domain))
+		domain->domain.geometry.aperture_end = __DOMAIN_MAX_ADDR(domain->gaw - 1);
+	else
+		domain->domain.geometry.aperture_end = __DOMAIN_MAX_ADDR(domain->gaw);
 }
 
 struct context_entry *iommu_context_addr(struct intel_iommu *iommu, u8 bus,
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>, Tom Murphy <murphyt7@tcd.ie>,
	David Woodhouse <dwmw2@infradead.org>,
	Christoph Hellwig <hch@infradead.org>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org
Subject: [PATCH v4 5/7] iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
Date: Sun, 27 Sep 2020 14:34:35 +0800	[thread overview]
Message-ID: <20200927063437.13988-6-baolu.lu@linux.intel.com> (raw)
In-Reply-To: <20200927063437.13988-1-baolu.lu@linux.intel.com>

The iommu-dma constrains IOVA allocation based on the domain geometry
that the driver reports. Update domain geometry everytime a domain is
attached to or detached from a device.

Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
 drivers/iommu/intel/iommu.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index fdd514c8b2d4..7d3c73d1e498 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -67,8 +67,8 @@
 #define MAX_AGAW_WIDTH 64
 #define MAX_AGAW_PFN_WIDTH	(MAX_AGAW_WIDTH - VTD_PAGE_SHIFT)
 
-#define __DOMAIN_MAX_PFN(gaw)  ((((uint64_t)1) << (gaw-VTD_PAGE_SHIFT)) - 1)
-#define __DOMAIN_MAX_ADDR(gaw) ((((uint64_t)1) << gaw) - 1)
+#define __DOMAIN_MAX_PFN(gaw)  ((((uint64_t)1) << ((gaw) - VTD_PAGE_SHIFT)) - 1)
+#define __DOMAIN_MAX_ADDR(gaw) ((((uint64_t)1) << (gaw)) - 1)
 
 /* We limit DOMAIN_MAX_PFN to fit in an unsigned long, and DOMAIN_MAX_ADDR
    to match. That way, we can use 'unsigned long' for PFNs with impunity. */
@@ -739,6 +739,18 @@ static void domain_update_iommu_cap(struct dmar_domain *domain)
 	 */
 	if (domain->nid == NUMA_NO_NODE)
 		domain->nid = domain_update_device_node(domain);
+
+	/*
+	 * First-level translation restricts the input-address to a
+	 * canonical address (i.e., address bits 63:N have the same
+	 * value as address bit [N-1], where N is 48-bits with 4-level
+	 * paging and 57-bits with 5-level paging). Hence, skip bit
+	 * [N-1].
+	 */
+	if (domain_use_first_level(domain))
+		domain->domain.geometry.aperture_end = __DOMAIN_MAX_ADDR(domain->gaw - 1);
+	else
+		domain->domain.geometry.aperture_end = __DOMAIN_MAX_ADDR(domain->gaw);
 }
 
 struct context_entry *iommu_context_addr(struct intel_iommu *iommu, u8 bus,
-- 
2.17.1

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>, Tom Murphy <murphyt7@tcd.ie>,
	David Woodhouse <dwmw2@infradead.org>,
	Christoph Hellwig <hch@infradead.org>
Cc: Ashok Raj <ashok.raj@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Intel-gfx@lists.freedesktop.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	Lu Baolu <baolu.lu@linux.intel.com>
Subject: [PATCH v4 5/7] iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
Date: Sun, 27 Sep 2020 14:34:35 +0800	[thread overview]
Message-ID: <20200927063437.13988-6-baolu.lu@linux.intel.com> (raw)
In-Reply-To: <20200927063437.13988-1-baolu.lu@linux.intel.com>

The iommu-dma constrains IOVA allocation based on the domain geometry
that the driver reports. Update domain geometry everytime a domain is
attached to or detached from a device.

Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
 drivers/iommu/intel/iommu.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index fdd514c8b2d4..7d3c73d1e498 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -67,8 +67,8 @@
 #define MAX_AGAW_WIDTH 64
 #define MAX_AGAW_PFN_WIDTH	(MAX_AGAW_WIDTH - VTD_PAGE_SHIFT)
 
-#define __DOMAIN_MAX_PFN(gaw)  ((((uint64_t)1) << (gaw-VTD_PAGE_SHIFT)) - 1)
-#define __DOMAIN_MAX_ADDR(gaw) ((((uint64_t)1) << gaw) - 1)
+#define __DOMAIN_MAX_PFN(gaw)  ((((uint64_t)1) << ((gaw) - VTD_PAGE_SHIFT)) - 1)
+#define __DOMAIN_MAX_ADDR(gaw) ((((uint64_t)1) << (gaw)) - 1)
 
 /* We limit DOMAIN_MAX_PFN to fit in an unsigned long, and DOMAIN_MAX_ADDR
    to match. That way, we can use 'unsigned long' for PFNs with impunity. */
@@ -739,6 +739,18 @@ static void domain_update_iommu_cap(struct dmar_domain *domain)
 	 */
 	if (domain->nid == NUMA_NO_NODE)
 		domain->nid = domain_update_device_node(domain);
+
+	/*
+	 * First-level translation restricts the input-address to a
+	 * canonical address (i.e., address bits 63:N have the same
+	 * value as address bit [N-1], where N is 48-bits with 4-level
+	 * paging and 57-bits with 5-level paging). Hence, skip bit
+	 * [N-1].
+	 */
+	if (domain_use_first_level(domain))
+		domain->domain.geometry.aperture_end = __DOMAIN_MAX_ADDR(domain->gaw - 1);
+	else
+		domain->domain.geometry.aperture_end = __DOMAIN_MAX_ADDR(domain->gaw);
 }
 
 struct context_entry *iommu_context_addr(struct intel_iommu *iommu, u8 bus,
-- 
2.17.1


  parent reply	other threads:[~2020-09-27  6:41 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-27  6:34 [Intel-gfx] [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api Lu Baolu
2020-09-27  6:34 ` Lu Baolu
2020-09-27  6:34 ` Lu Baolu
2020-09-27  6:34 ` [Intel-gfx] [PATCH v4 1/7] iommu: Handle freelists when using deferred flushing in iommu drivers Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34 ` [Intel-gfx] [PATCH v4 2/7] iommu: Add iommu_dma_free_cpu_cached_iovas() Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34 ` [Intel-gfx] [PATCH v4 3/7] iommu: Allow the dma-iommu api to use bounce buffers Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34 ` [Intel-gfx] [PATCH v4 4/7] iommu: Add quirk for Intel graphic devices in map_sg Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-11-03 12:00   ` [Intel-gfx] " Robin Murphy
2020-11-03 12:00     ` Robin Murphy
2020-11-03 12:00     ` Robin Murphy
2020-09-27  6:34 ` Lu Baolu [this message]
2020-09-27  6:34   ` [PATCH v4 5/7] iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34 ` [Intel-gfx] [PATCH v4 6/7] iommu/vt-d: Convert intel iommu driver to the iommu ops Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:34 ` [Intel-gfx] [PATCH v4 7/7] iommu/vt-d: Cleanup after converting to dma-iommu ops Lu Baolu
2020-09-27  6:34   ` Lu Baolu
2020-09-27  6:47 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Convert the intel iommu driver to the dma-iommu api (rev3) Patchwork
2020-09-28  9:44 ` [Intel-gfx] [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api Tvrtko Ursulin
2020-09-28  9:44   ` Tvrtko Ursulin
2020-09-28  9:44   ` Tvrtko Ursulin
2020-09-29  0:11   ` [Intel-gfx] " Lu Baolu
2020-09-29  0:11     ` Lu Baolu
2020-09-29  0:11     ` Lu Baolu
2020-10-01 12:17     ` [Intel-gfx] " Joerg Roedel
2020-10-01 12:17       ` Joerg Roedel
2020-10-01 12:17       ` Joerg Roedel
2020-10-02 11:59       ` [Intel-gfx] " Lu Baolu
2020-10-02 11:59         ` Lu Baolu
2020-10-02 11:59         ` Lu Baolu
2020-10-12  8:44     ` [Intel-gfx] " Tvrtko Ursulin
2020-10-12  8:44       ` Tvrtko Ursulin
2020-10-12  8:44       ` Tvrtko Ursulin
2020-10-13  0:32       ` [Intel-gfx] " Lu Baolu
2020-10-13  0:32         ` Lu Baolu
2020-10-13  0:32         ` Lu Baolu
2020-11-02  2:00       ` [Intel-gfx] " Lu Baolu
2020-11-02  2:00         ` Lu Baolu
2020-11-02  2:00         ` Lu Baolu
2020-11-02 11:52         ` [Intel-gfx] " Tvrtko Ursulin
2020-11-02 11:52           ` Tvrtko Ursulin
2020-11-02 11:52           ` Tvrtko Ursulin
2020-11-03  2:53           ` [Intel-gfx] " Lu Baolu
2020-11-03  2:53             ` Lu Baolu
2020-11-03  2:53             ` Lu Baolu
2020-11-03  9:14             ` [Intel-gfx] " Tvrtko Ursulin
2020-11-03  9:14               ` Tvrtko Ursulin
2020-11-03  9:14               ` Tvrtko Ursulin
2020-11-03  9:58               ` [Intel-gfx] " Joonas Lahtinen
2020-11-03  9:58                 ` Joonas Lahtinen
2020-11-03  9:58                 ` Joonas Lahtinen
2020-11-03 10:54                 ` [Intel-gfx] " Joerg Roedel
2020-11-03 10:54                   ` Joerg Roedel
2020-11-03 10:54                   ` Joerg Roedel
2020-11-20 10:20                   ` [Intel-gfx] " Lu Baolu
2020-11-20 10:20                     ` Lu Baolu
2020-11-20 10:20                     ` Lu Baolu
2020-10-01 21:17 ` [Intel-gfx] " Logan Gunthorpe
2020-10-01 21:17   ` Logan Gunthorpe
2020-10-01 21:17   ` Logan Gunthorpe

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=20200927063437.13988-6-baolu.lu@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=ashok.raj@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=murphyt7@tcd.ie \
    /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.