RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe devices
-Original Message-
From: Bhushan Bharat-R65777
Sent: Wednesday, October 16, 2013 10:20 PM
To: Sethi Varun-B16395; j...@8bytes.org; iommu@lists.linux-
foundation.org; linuxppc-...@lists.ozlabs.org; linux-
ker...@vger.kernel.org; Yoder Stuart-B08248; Wood Scott-B07421;
alex.william...@redhat.com
Subject: RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe
devices
-Original Message-
From: Sethi Varun-B16395
Sent: Wednesday, October 16, 2013 4:53 PM
To: j...@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Yoder
Stuart-B08248; Wood Scott-B07421; alex.william...@redhat.com; Bhushan
Bharat-R65777
Cc: Sethi Varun-B16395
Subject: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe
devices
Once the PCIe device assigned to a guest VM (via VFIO) gets detached
from the iommu domain (when guest terminates), its PAMU table entry is
disabled. So, this would prevent the device from being used once it's
assigned back to the host.
This patch allows for creation of a default DMA window corresponding
to the device and subsequently enabling the PAMU table entry. Before
we enable the entry, we ensure that the device's bus master capability
is disabled (device quiesced).
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
drivers/iommu/fsl_pamu.c| 43 ---
-
drivers/iommu/fsl_pamu.h|1 +
drivers/iommu/fsl_pamu_domain.c | 46
---
3 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c index
cba0498..fb4a031 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -225,6 +225,21 @@ static struct paace *pamu_get_spaace(struct paace
*paace,
u32 wnum)
return spaace;
}
+/*
+ * Defaul PPAACE settings for an LIODN.
+ */
+static void setup_default_ppaace(struct paace *ppaace) {
+ pamu_init_ppaace(ppaace);
+ /* window size is 2^(WSE+1) bytes */
+ set_bf(ppaace-addr_bitfields, PPAACE_AF_WSE, 35);
+ ppaace-wbah = 0;
+ set_bf(ppaace-addr_bitfields, PPAACE_AF_WBAL, 0);
+ set_bf(ppaace-impl_attr, PAACE_IA_ATM,
+ PAACE_ATM_NO_XLATE);
+ set_bf(ppaace-addr_bitfields, PAACE_AF_AP,
+ PAACE_AP_PERMS_ALL);
+}
/**
* pamu_get_fspi_and_allocate() - Allocates fspi index and reserves
subwindows
*required for primary PAACE in the
secondary
@@ -253,6 +268,24 @@ static unsigned long
pamu_get_fspi_and_allocate(u32
subwin_cnt)
return (spaace_addr - (unsigned long)spaact) / (sizeof(struct
paace)); }
+/* Reset the PAACE entry to the default state */ void
+enable_default_dma_window(int liodn) {
+ struct paace *ppaace;
+
+ ppaace = pamu_get_ppaace(liodn);
+ if (!ppaace) {
+ pr_debug(Invalid liodn entry\n);
+ return;
+ }
+
+ memset(ppaace, 0, sizeof(struct paace));
+
+ setup_default_ppaace(ppaace);
+ mb();
+ pamu_enable_liodn(liodn);
+}
+
/* Release the subwindows reserved for a particular LIODN */ void
pamu_free_subwins(int liodn) { @@ -752,15 +785,7 @@ static void
__init
setup_liodns(void)
continue;
}
ppaace = pamu_get_ppaace(liodn);
- pamu_init_ppaace(ppaace);
- /* window size is 2^(WSE+1) bytes */
- set_bf(ppaace-addr_bitfields, PPAACE_AF_WSE, 35);
- ppaace-wbah = 0;
- set_bf(ppaace-addr_bitfields, PPAACE_AF_WBAL, 0);
- set_bf(ppaace-impl_attr, PAACE_IA_ATM,
- PAACE_ATM_NO_XLATE);
- set_bf(ppaace-addr_bitfields, PAACE_AF_AP,
- PAACE_AP_PERMS_ALL);
+ setup_default_ppaace(ppaace);
if (of_device_is_compatible(node, fsl,qman-portal))
setup_qbman_paace(ppaace, QMAN_PORTAL_PAACE);
if (of_device_is_compatible(node, fsl,qman)) diff --
git
a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h index
8fc1a12..0edc
100644
--- a/drivers/iommu/fsl_pamu.h
+++ b/drivers/iommu/fsl_pamu.h
@@ -406,5 +406,6 @@ void get_ome_index(u32 *omi_index, struct device
*dev); int pamu_update_paace_stash(int liodn, u32 subwin, u32 value);
int pamu_disable_spaace(int liodn, u32 subwin);
u32 pamu_get_max_subwin_cnt(void);
+void enable_default_dma_window(int liodn);
#endif /* __FSL_PAMU_H */
diff --git a/drivers/iommu/fsl_pamu_domain.c
b/drivers/iommu/fsl_pamu_domain.c index 966ae70..dd6cafc 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -340,17 +340,57 @@ static inline struct
RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe devices
-Original Message-
From: Bhushan Bharat-R65777
Sent: Wednesday, October 16, 2013 10:43 PM
To: Sethi Varun-B16395; j...@8bytes.org; iommu@lists.linux-
foundation.org; linuxppc-...@lists.ozlabs.org; linux-
ker...@vger.kernel.org; Yoder Stuart-B08248; Wood Scott-B07421;
alex.william...@redhat.com
Subject: RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe
devices
-Original Message-
From: Sethi Varun-B16395
Sent: Wednesday, October 16, 2013 4:53 PM
To: j...@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Yoder
Stuart-B08248; Wood Scott-B07421; alex.william...@redhat.com;
Bhushan
Bharat-R65777
Cc: Sethi Varun-B16395
Subject: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for
PCIe devices
Once the PCIe device assigned to a guest VM (via VFIO) gets
detached from the iommu domain (when guest terminates), its PAMU
table entry is disabled. So, this would prevent the device from
being used once it's
assigned back to the host.
This patch allows for creation of a default DMA window
corresponding to the device and subsequently enabling the PAMU
table entry. Before we enable the entry, we ensure that the
device's bus master capability is disabled (device quiesced).
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
drivers/iommu/fsl_pamu.c| 43
---
-
drivers/iommu/fsl_pamu.h|1 +
drivers/iommu/fsl_pamu_domain.c | 46
---
3 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index
cba0498..fb4a031 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -225,6 +225,21 @@ static struct paace *pamu_get_spaace(struct
paace *paace,
u32 wnum)
return spaace;
}
+/*
+ * Defaul PPAACE settings for an LIODN.
+ */
+static void setup_default_ppaace(struct paace *ppaace) {
+ pamu_init_ppaace(ppaace);
+ /* window size is 2^(WSE+1) bytes */
+ set_bf(ppaace-addr_bitfields, PPAACE_AF_WSE, 35);
+ ppaace-wbah = 0;
+ set_bf(ppaace-addr_bitfields, PPAACE_AF_WBAL, 0);
+ set_bf(ppaace-impl_attr, PAACE_IA_ATM,
+ PAACE_ATM_NO_XLATE);
+ set_bf(ppaace-addr_bitfields, PAACE_AF_AP,
+ PAACE_AP_PERMS_ALL);
+}
/**
* pamu_get_fspi_and_allocate() - Allocates fspi index and
reserves
subwindows
*required for primary PAACE in
the
secondary
@@ -253,6 +268,24 @@ static unsigned long
pamu_get_fspi_and_allocate(u32
subwin_cnt)
return (spaace_addr - (unsigned long)spaact) / (sizeof(struct
paace)); }
+/* Reset the PAACE entry to the default state */ void
+enable_default_dma_window(int liodn) {
+ struct paace *ppaace;
+
+ ppaace = pamu_get_ppaace(liodn);
+ if (!ppaace) {
+ pr_debug(Invalid liodn entry\n);
+ return;
+ }
+
+ memset(ppaace, 0, sizeof(struct paace));
+
+ setup_default_ppaace(ppaace);
+ mb();
+ pamu_enable_liodn(liodn);
+}
+
/* Release the subwindows reserved for a particular LIODN */
void pamu_free_subwins(int liodn) { @@ -752,15 +785,7 @@ static
void __init
setup_liodns(void)
continue;
}
ppaace = pamu_get_ppaace(liodn);
- pamu_init_ppaace(ppaace);
- /* window size is 2^(WSE+1) bytes */
- set_bf(ppaace-addr_bitfields, PPAACE_AF_WSE,
35);
- ppaace-wbah = 0;
- set_bf(ppaace-addr_bitfields, PPAACE_AF_WBAL,
0);
- set_bf(ppaace-impl_attr, PAACE_IA_ATM,
- PAACE_ATM_NO_XLATE);
- set_bf(ppaace-addr_bitfields, PAACE_AF_AP,
- PAACE_AP_PERMS_ALL);
+ setup_default_ppaace(ppaace);
if (of_device_is_compatible(node, fsl,qman-
portal))
setup_qbman_paace(ppaace,
QMAN_PORTAL_PAACE);
if (of_device_is_compatible(node, fsl,qman))
diff --
git
a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h index
8fc1a12..0edc
100644
--- a/drivers/iommu/fsl_pamu.h
+++ b/drivers/iommu/fsl_pamu.h
@@ -406,5 +406,6 @@ void get_ome_index(u32 *omi_index, struct
device *dev); int pamu_update_paace_stash(int liodn, u32 subwin,
u32 value); int
RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe devices
-Original Message-
From: Bhushan Bharat-R65777
Sent: Wednesday, October 16, 2013 10:52 PM
To: Sethi Varun-B16395; j...@8bytes.org; iommu@lists.linux-
foundation.org; linuxppc-...@lists.ozlabs.org; linux-
ker...@vger.kernel.org; Yoder Stuart-B08248; Wood Scott-B07421;
alex.william...@redhat.com
Subject: RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe
devices
-Original Message-
From: Sethi Varun-B16395
Sent: Wednesday, October 16, 2013 4:53 PM
To: j...@8bytes.org; iommu@lists.linux-foundation.org;
linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
Yoder Stuart-B08248; Wood Scott-B07421;
alex.william...@redhat.com; Bhushan
Bharat-R65777
Cc: Sethi Varun-B16395
Subject: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window
for PCIe devices
Once the PCIe device assigned to a guest VM (via VFIO) gets
detached from the iommu domain (when guest terminates), its
PAMU table entry is disabled. So, this would prevent the
device from being used once it's
assigned back to the host.
This patch allows for creation of a default DMA window
corresponding to the device and subsequently enabling the PAMU
table entry. Before we enable the entry, we ensure that the
device's bus master capability is disabled (device quiesced).
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
drivers/iommu/fsl_pamu.c| 43
---
-
drivers/iommu/fsl_pamu.h|1 +
drivers/iommu/fsl_pamu_domain.c | 46
---
3 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/fsl_pamu.c
b/drivers/iommu/fsl_pamu.c index
cba0498..fb4a031 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -225,6 +225,21 @@ static struct paace
*pamu_get_spaace(struct paace *paace,
u32 wnum)
return spaace;
}
+/*
+ * Defaul PPAACE settings for an LIODN.
+ */
+static void setup_default_ppaace(struct paace *ppaace) {
+ pamu_init_ppaace(ppaace);
+ /* window size is 2^(WSE+1) bytes */
+ set_bf(ppaace-addr_bitfields, PPAACE_AF_WSE, 35);
+ ppaace-wbah = 0;
+ set_bf(ppaace-addr_bitfields, PPAACE_AF_WBAL, 0);
+ set_bf(ppaace-impl_attr, PAACE_IA_ATM,
+ PAACE_ATM_NO_XLATE);
+ set_bf(ppaace-addr_bitfields, PAACE_AF_AP,
+ PAACE_AP_PERMS_ALL);
+}
/**
* pamu_get_fspi_and_allocate() - Allocates fspi index and
reserves
subwindows
*required for primary PAACE
in
the
secondary
@@ -253,6 +268,24 @@ static unsigned long
pamu_get_fspi_and_allocate(u32
subwin_cnt)
return (spaace_addr - (unsigned long)spaact) /
(sizeof(struct paace)); }
+/* Reset the PAACE entry to the default state */ void
+enable_default_dma_window(int liodn) {
+ struct paace *ppaace;
+
+ ppaace = pamu_get_ppaace(liodn);
+ if (!ppaace) {
+ pr_debug(Invalid liodn entry\n);
+ return;
+ }
+
+ memset(ppaace, 0, sizeof(struct paace));
+
+ setup_default_ppaace(ppaace);
+ mb();
+ pamu_enable_liodn(liodn);
+}
+
/* Release the subwindows reserved for a particular LIODN */
void pamu_free_subwins(int liodn) { @@ -752,15 +785,7 @@
static void __init
setup_liodns(void)
continue;
}
ppaace = pamu_get_ppaace(liodn);
- pamu_init_ppaace(ppaace);
- /* window size is 2^(WSE+1) bytes */
- set_bf(ppaace-addr_bitfields, PPAACE_AF_WSE,
35);
- ppaace-wbah = 0;
- set_bf(ppaace-addr_bitfields, PPAACE_AF_WBAL,
0);
- set_bf(ppaace-impl_attr, PAACE_IA_ATM,
- PAACE_ATM_NO_XLATE);
- set_bf(ppaace-addr_bitfields, PAACE_AF_AP,
- PAACE_AP_PERMS_ALL);
+ setup_default_ppaace(ppaace);
if (of_device_is_compatible(node, fsl,qman-
portal))
setup_qbman_paace(ppaace,
QMAN_PORTAL_PAACE);
if (of_device_is_compatible(node, fsl,qman))
diff --
git
a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h index
8fc1a12..0edc
100644
--- a/drivers/iommu/fsl_pamu.h
+++ b/drivers/iommu/fsl_pamu.h
@@ -406,5 +406,6 @@ void get_ome_index(u32 *omi_index, struct
RE: [PATCH 2/7] iommu: add api to get iommu_domain of a device
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Friday, October 11, 2013 2:12 AM
To: Sethi Varun-B16395
Cc: Bhushan Bharat-R65777; ag...@suse.de; Wood Scott-B07421; linux-
p...@vger.kernel.org; ga...@kernel.crashing.org; linux-
ker...@vger.kernel.org; iommu@lists.linux-foundation.org;
b...@kernel.crashing.org; linuxppc-...@lists.ozlabs.org
Subject: Re: [PATCH 2/7] iommu: add api to get iommu_domain of a device
On Thu, 2013-10-10 at 20:09 +, Sethi Varun-B16395 wrote:
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
Sent: Tuesday, October 08, 2013 8:43 AM
To: Bhushan Bharat-R65777
Cc: ag...@suse.de; Wood Scott-B07421; linux-...@vger.kernel.org;
ga...@kernel.crashing.org; linux-ker...@vger.kernel.org;
iommu@lists.linux-foundation.org; b...@kernel.crashing.org;
linuxppc- d...@lists.ozlabs.org
Subject: Re: [PATCH 2/7] iommu: add api to get iommu_domain of a
device
On Mon, 2013-10-07 at 05:46 +, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Friday, October 04, 2013 11:42 PM
To: Bhushan Bharat-R65777
Cc: j...@8bytes.org; b...@kernel.crashing.org;
ga...@kernel.crashing.org; linux- ker...@vger.kernel.org;
linuxppc-...@lists.ozlabs.org; linux- p...@vger.kernel.org;
ag...@suse.de; Wood Scott-B07421; iommu@lists.linux-
foundation.org
Subject: Re: [PATCH 2/7] iommu: add api to get iommu_domain of a
device
On Fri, 2013-10-04 at 17:23 +, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Friday, October 04, 2013 10:43 PM
To: Bhushan Bharat-R65777
Cc: j...@8bytes.org; b...@kernel.crashing.org;
ga...@kernel.crashing.org; linux- ker...@vger.kernel.org;
linuxppc-...@lists.ozlabs.org; linux- p...@vger.kernel.org;
ag...@suse.de; Wood Scott-B07421; iommu@lists.linux-
foundation.org
Subject: Re: [PATCH 2/7] iommu: add api to get iommu_domain
of a device
On Fri, 2013-10-04 at 16:47 +, Bhushan Bharat-R65777
wrote:
-Original Message-
From: Alex Williamson
[mailto:alex.william...@redhat.com]
Sent: Friday, October 04, 2013 9:15 PM
To: Bhushan Bharat-R65777
Cc: j...@8bytes.org; b...@kernel.crashing.org;
ga...@kernel.crashing.org; linux-
ker...@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
linux- p...@vger.kernel.org; ag...@suse.de; Wood
Scott-B07421; iommu@lists.linux- foundation.org
Subject: Re: [PATCH 2/7] iommu: add api to get
iommu_domain of a device
On Fri, 2013-10-04 at 09:54 +, Bhushan Bharat-R65777
wrote:
-Original Message-
From: linux-pci-ow...@vger.kernel.org
[mailto:linux-pci-ow...@vger.kernel.org]
On Behalf Of Alex Williamson
Sent: Wednesday, September 25, 2013 10:16 PM
To: Bhushan Bharat-R65777
Cc: j...@8bytes.org; b...@kernel.crashing.org;
ga...@kernel.crashing.org; linux-
ker...@vger.kernel.org;
linuxppc-...@lists.ozlabs.org;
linux- p...@vger.kernel.org; ag...@suse.de; Wood
Scott-B07421; iommu@lists.linux- foundation.org;
Bhushan
Bharat-R65777
Subject: Re: [PATCH 2/7] iommu: add api to get
iommu_domain of a device
On Thu, 2013-09-19 at 12:59 +0530, Bharat Bhushan
wrote:
This api return the iommu domain to which the
device is
attached.
The iommu_domain is required for making API calls
related to
iommu.
Follow up patches which use this API to know iommu
maping.
Signed-off-by: Bharat Bhushan
bharat.bhus...@freescale.com
---
drivers/iommu/iommu.c | 10 ++
include/linux/iommu.h |7 +++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/iommu.c
b/drivers/iommu/iommu.c index
fbe9ca7..6ac5f50 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -696,6 +696,16 @@ void
iommu_detach_device(struct iommu_domain *domain,
struct device *dev) }
EXPORT_SYMBOL_GPL(iommu_detach_device);
+struct iommu_domain *iommu_get_dev_domain(struct
device *dev) {
+ struct iommu_ops *ops = dev-bus-iommu_ops;
+
+ if (unlikely(ops == NULL ||
+ops
RE: [PATCH 2/7] iommu: add api to get iommu_domain of a device
sure that your use of the interface is race free. The interface itself needs to be designed so that it's difficult to use incorrectly. So we can define iommu_get_dev_domain()/iommu_put_dev_domain(); iommu_get_dev_domain() will return domain with the lock held, and iommu_put_dev_domain() will release the lock? And iommu_get_dev_domain() must always be followed by iommu_get_dev_domain(). What lock? get/put are generally used for reference counting, not locking in the kernel. That's not the case here. This is a backdoor to get the iommu domain from the iommu driver regardless of who is using it or how. The iommu domain is created and managed by vfio, so shouldn't we be looking at how to do this through vfio? Let me first describe what we are doing here: During initialization:- - vfio talks to MSI system to know the MSI-page and size - vfio then interacts with iommu to map the MSI-page in iommu (IOVA is decided by userspace and physical address is the MSI-page) - So the IOVA subwindow mapping is created in iommu and yes VFIO know about this mapping. Now do SET_IRQ(MSI/MSIX) ioctl: - calls pci_enable_msix()/pci_enable_msi_block(): which is supposed to set MSI address/data in device. - So in current implementation (this patchset) msi-subsystem gets the IOVA from iommu via this defined interface. - Are you saying that rather than getting this from iommu, we should get this from vfio? What difference does this make? Yes, you just said above that vfio knows the msi to iova mapping, so why go outside of vfio to find it later? The difference is one case you can have a proper reference to data structures to make sure the pointer you get back actually has meaning at the time you're using it vs the code here where you're defining an API that returns a meaningless value With FSL-PAMU we will always get consistant data from iommu or vfio-data structure. Great, but you're trying to add a generic API to the IOMMU subsystem that's difficult to use correctly. The fact that you use it correctly does not justify the API. because you can't check or enforce that an arbitrary caller is using it correctly. I am not sure what is arbitrary caller? pdev is known to vfio, so vfio will only make pci_enable_msix()/pci_enable_msi_block() for this pdev. If anyother code makes then it is some other unexpectedly thing happening in system, no? What's proposed here is a generic IOMMU API. Anybody can call this. What if the host SCSI driver decides to go get the iommu domain for it's device (or any other device)? Does that fit your usage model? It's not maintainable. Thanks, I do not have any issue with this as well, can you also describe the type of API you are envisioning; I can think of defining some function in vfio.c/vfio_iommu*.c, make them global and declare then in include/Linux/vfio.h And include Linux/vfio.h in caller file (arch/powerpc/kernel/msi.c) Do you really want module dependencies between vfio and your core kernel MSI setup? Look at the vfio external user interface that we've already defined. That allows other components of the kernel to get a proper reference to a vfio group. From there you can work out how to get what you want. Another alternative is that vfio could register an MSI to IOVA mapping with architecture code when the mapping is created. The MSI setup path could then do a lookup in architecture code for the mapping. You could even store the MSI to IOVA mapping in VFIO and create an interface where SET_IRQ passes that mapping into setup code. [Sethi Varun-B16395] What you are suggesting is that the MSI setup path queries the vfio subsystem for the mapping, rather than directly querying the iommu subsystem. So, say if we add an interface for getting MSI to IOVA mapping in the msi setup path, wouldn't this again be specific to vfio? I reckon that this interface would again ppc machine specific interface. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 3/5] iommu/arm-smmu: Introduce stream ID masking
-Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Will Deacon Sent: Tuesday, October 08, 2013 10:29 PM To: Andreas Herrmann Cc: iommu@lists.linux-foundation.org; Rob Herring; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] iommu/arm-smmu: Introduce stream ID masking On Tue, Oct 08, 2013 at 05:40:21PM +0100, Andreas Herrmann wrote: On Tue, Oct 08, 2013 at 05:20:08PM +0200, Andreas Herrmann wrote: To be more specific: For SATA I'd need to specify 10 StreamIds. This would (1) exceed MAX_MASTER_STREAMIDS (currently it's 8) (Can easily be fixed by adapting a macro.) (2) exceed number of available SMR groups to map the IDs to a context. This can be solved by caclulating an appropriate mask for the mapping (but with a non-power-of-two number of StreamIds that's already non-trivial -- for the trivial case I have some code to do this). Both problems are avoided by introducing this patch -- use smr_mask_bits to map all StreamIDs to the same context and be done with it. (for the single-master-SMMU case) The problem is, this information *really* doesn't belong in the device tree, but I think computing the general case dynamically is incredibly difficult too (and requires *complete* topological information in the device-tree, so you don't accidentally pull in other devices). [Sethi Varun-B16395] I don't quiet follow the point about topological information. How do you determine from the topology if the stream ids should share the iommu domain? Another question, how would iommu group creation work for dma masters with multiple stream ids? -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/2] vfio: hugepage support for vfio_iommu_type1
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
Sent: Friday, May 24, 2013 10:55 PM
To: alex.william...@redhat.com
Cc: iommu@lists.linux-foundation.org; chegu_vi...@hp.com; qemu-
de...@nongnu.org; k...@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: [PATCH 2/2] vfio: hugepage support for vfio_iommu_type1
We currently send all mappings to the iommu in PAGE_SIZE chunks, which
prevents the iommu from enabling support for larger page sizes.
We still need to pin pages, which means we step through them in PAGE_SIZE
chunks, but we can batch up contiguous physical memory chunks to allow
the iommu the opportunity to use larger pages. The approach here is a
bit different that the one currently used for legacy KVM device
assignment. Rather than looking at the vma page size and using that as
the maximum size to pass to the iommu, we instead simply look at whether
the next page is physically contiguous. This means we might ask the
iommu to map a 4MB region, while legacy KVM might limit itself to a
[Sethi Varun-B16395] Wouldn't this depend on the IOMMU page alignment
constraints?
maximum of 2MB.
Splitting our mapping path also allows us to be smarter about locked
memory because we can more easily unwind if the user attempts to exceed
the limit. Therefore, rather than assuming that a mapping will result in
locked memory, we test each page as it is pinned to determine whether it
locks RAM vs an mmap'd MMIO region. This should result in better locking
granularity and less locked page fudge factors in userspace.
The unmap path uses the same algorithm as legacy KVM. We don't want to
track the pfn for each mapping ourselves, but we need the pfn in order to
unpin pages. We therefore ask the iommu for the iova to physical address
translation, ask it to unpin a page, and see how many pages were actually
unpinned. iommus supporting large pages will often return something
bigger than a page here, which we know will be physically contiguous and
we can unpin a batch of pfns. iommus not supporting large mappings won't
see an improvement in batching here as they only unmap a page at a time.
With this change, we also make a clarification to the API for mapping and
unmapping DMA. We can only guarantee unmaps at the same granularity as
used for the original mapping. In other words, unmapping a subregion of
a previous mapping is not guaranteed and may result in a larger or
smaller unmapping than requested. The size field in the unmapping
structure is updated to reflect this.
Previously this was unmodified on mapping, always returning the the
requested unmap size. This is now updated to return the actual unmap
size on success, allowing userspace to appropriately track mappings.
[Sethi Varun-B16395] The main problem here is that the user space application
is oblivious of the physical memory contiguity, right?
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/vfio/vfio_iommu_type1.c | 523 +
--
+static long vfio_unpin_pages(unsigned long pfn, long npage,
+ int prot, bool do_accounting)
+{
+ unsigned long unlocked = 0;
+ long i;
+
+ for (i = 0; i npage; i++)
+ unlocked += put_pfn(pfn++, prot);
+
+ if (do_accounting)
+ vfio_lock_acct(-unlocked);
+
+ return unlocked;
+}
+
+static int vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma
*dma,
+ dma_addr_t iova, size_t *size)
+{
+ dma_addr_t start = iova, end = iova + *size;
+ long unlocked = 0;
+
+ while (iova end) {
+ size_t unmapped;
+ phys_addr_t phys;
+
/*
- * Only add actual locked pages to accounting
- * XXX We're effectively marking a page locked for every
- * IOVA page even though it's possible the user could be
- * backing multiple IOVAs with the same vaddr. This over-
- * penalizes the user process, but we currently have no
- * easy way to do this properly.
+ * We use the IOMMU to track the physical address. This
+ * saves us from having a lot more entries in our mapping
+ * tree. The downside is that we don't track the size
+ * used to do the mapping. We request unmap of a single
+ * page, but expect IOMMUs that support large pages to
+ * unmap a larger chunk.
*/
- if (!is_invalid_reserved_pfn(pfn))
- locked++;
-
- ret = iommu_map(iommu-domain, iova,
- (phys_addr_t)pfn PAGE_SHIFT,
- PAGE_SIZE, prot);
- if (ret) {
- /* Back out mappings on error
RE: [PATCH 1/3] pci: Add PCI walk function and PCIe bridge test
Any idea when would this patch set be integrated? Freescale PAMU driver depends
on this patch. Currently I am using the pci_find_pcie_upstream_bridge routine
in the device group creation routine.
-Varun
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Monday, May 13, 2013 8:19 PM
To: Sethi Varun-B16395
Cc: bhelg...@google.com; step...@networkplumber.org; linux-
p...@vger.kernel.org; iommu@lists.linux-foundation.org;
dw...@infradead.org
Subject: Re: [PATCH 1/3] pci: Add PCI walk function and PCIe bridge test
On Mon, 2013-05-13 at 13:51 +, Sethi Varun-B16395 wrote:
Would these functions be used outside drivers/iommu? We recently added
pci.h under drivers/iommu, maybe we can add a new file for these
functions as well.
The intention is to make them generic enough for pci-core, unlike
pci_find_upstream_pcie_bridge, which was rather specific to iommu usage.
Thanks,
Alex
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
Sent: Saturday, May 11, 2013 2:49 AM
To: bhelg...@google.com; step...@networkplumber.org
Cc: linux-...@vger.kernel.org; iommu@lists.linux-foundation.org;
dw...@infradead.org
Subject: [PATCH 1/3] pci: Add PCI walk function and PCIe bridge test
These will replace pci_find_upstream_pcie_bridge, which is difficult
to use and rather specific to intel-iommu usage. A quirked
pci_is_pcie_bridge function is provided to work around non-compliant
PCIe-to-PCI bridges such as those found in
https://bugzilla.kernel.org/show_bug.cgi?id=44881
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/search.c | 57
++
include/linux/pci.h | 23
2 files changed, 80 insertions(+)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c index
d0627fa..0357f74 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -17,6 +17,63 @@
DECLARE_RWSEM(pci_bus_sem);
EXPORT_SYMBOL_GPL(pci_bus_sem);
+/* Test for PCIe bridges. */
+bool pci_is_pcie_bridge(struct pci_dev *pdev) {
+ if (!pci_is_bridge(pdev))
+ return false;
+
+ if (pci_is_pcie(pdev))
+ return true;
+
+#ifdef CONFIG_PCI_QUIRKS
+ /*
+ * If we're not on the root bus, look one device upstream of the
+ * current device. If that device is PCIe and is not a PCIe-to-PCI
+ * bridge, then the current device is effectively PCIe as it must
+ * be the PCIe-to-PCI bridge. This handles several bridges that
+ * violate the PCIe spec by not exposing a PCIe capability:
+ * https://bugzilla.kernel.org/show_bug.cgi?id=44881
+ */
+ if (!pci_is_root_bus(pdev-bus)) {
+ struct pci_dev *parent = pdev-bus-self;
+
+ if (pci_is_pcie(parent)
+ pci_pcie_type(parent) != PCI_EXP_TYPE_PCI_BRIDGE)
+
+ return true;
+ }
+#endif
+ return false;
+}
+
+/*
+ * Walk upstream from the given pdev for the first device returning
+ * true for the provided match function. If no match is found,
+return
+ * NULL. *last records the previous step in the walk.
+ */
+struct pci_dev *pci_walk_up_to_first_match(struct pci_dev *pdev,
+bool (*match)(struct pci_dev *),
+struct pci_dev **last)
+{
+ *last = NULL;
+
+ if (match(pdev))
+ return pdev;
+
+ *last = pdev;
+
+ while (!pci_is_root_bus(pdev-bus)) {
+ *last = pdev;
+ pdev = pdev-bus-self;
+
+ if (match(pdev))
+ return pdev;
+ }
+
+ return NULL;
+}
+
/*
* find the upstream PCIe-to-PCI bridge of a PCI device
* if the device is PCIE, return NULL diff --git
a/include/linux/pci.h b/include/linux/pci.h index bd8ec30..e87423a
100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1855,6 +1855,29 @@ static inline struct eeh_dev
*pci_dev_to_eeh_dev(struct pci_dev *pdev) #endif
/**
+ * pci_walk_up_to_first_match - Generic upstream search function
+ * @pdev: starting PCI device to search
+ * @match: match function to call on each device (true = match)
+ * @last: last device examined prior to returned device
+ *
+ * Walk upstream from the given device, calling match() at each
device.
+ * Returns the first device matching match(). If the root bus is
+reached
+ * without finding a match, return NULL. last returns the N-1 step
+in
+ * the search path.
+ */
+struct pci_dev *pci_walk_up_to_first_match(struct pci_dev *pdev,
+bool (*match)(struct pci_dev *),
+struct pci_dev **last
RE: [PATCH 1/3] pci: Add PCI walk function and PCIe bridge test
Would these functions be used outside drivers/iommu? We recently added pci.h
under drivers/iommu, maybe we can add a new file for these functions as well.
-Varun
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
Sent: Saturday, May 11, 2013 2:49 AM
To: bhelg...@google.com; step...@networkplumber.org
Cc: linux-...@vger.kernel.org; iommu@lists.linux-foundation.org;
dw...@infradead.org
Subject: [PATCH 1/3] pci: Add PCI walk function and PCIe bridge test
These will replace pci_find_upstream_pcie_bridge, which is difficult to
use and rather specific to intel-iommu usage. A quirked
pci_is_pcie_bridge function is provided to work around non-compliant
PCIe-to-PCI bridges such as those found in
https://bugzilla.kernel.org/show_bug.cgi?id=44881
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/pci/search.c | 57
++
include/linux/pci.h | 23
2 files changed, 80 insertions(+)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c index
d0627fa..0357f74 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -17,6 +17,63 @@
DECLARE_RWSEM(pci_bus_sem);
EXPORT_SYMBOL_GPL(pci_bus_sem);
+/* Test for PCIe bridges. */
+bool pci_is_pcie_bridge(struct pci_dev *pdev) {
+ if (!pci_is_bridge(pdev))
+ return false;
+
+ if (pci_is_pcie(pdev))
+ return true;
+
+#ifdef CONFIG_PCI_QUIRKS
+ /*
+ * If we're not on the root bus, look one device upstream of the
+ * current device. If that device is PCIe and is not a PCIe-to-PCI
+ * bridge, then the current device is effectively PCIe as it must
+ * be the PCIe-to-PCI bridge. This handles several bridges that
+ * violate the PCIe spec by not exposing a PCIe capability:
+ * https://bugzilla.kernel.org/show_bug.cgi?id=44881
+ */
+ if (!pci_is_root_bus(pdev-bus)) {
+ struct pci_dev *parent = pdev-bus-self;
+
+ if (pci_is_pcie(parent)
+ pci_pcie_type(parent) != PCI_EXP_TYPE_PCI_BRIDGE)
+
+ return true;
+ }
+#endif
+ return false;
+}
+
+/*
+ * Walk upstream from the given pdev for the first device returning
+ * true for the provided match function. If no match is found, return
+ * NULL. *last records the previous step in the walk.
+ */
+struct pci_dev *pci_walk_up_to_first_match(struct pci_dev *pdev,
+bool (*match)(struct pci_dev *),
+struct pci_dev **last)
+{
+ *last = NULL;
+
+ if (match(pdev))
+ return pdev;
+
+ *last = pdev;
+
+ while (!pci_is_root_bus(pdev-bus)) {
+ *last = pdev;
+ pdev = pdev-bus-self;
+
+ if (match(pdev))
+ return pdev;
+ }
+
+ return NULL;
+}
+
/*
* find the upstream PCIe-to-PCI bridge of a PCI device
* if the device is PCIE, return NULL
diff --git a/include/linux/pci.h b/include/linux/pci.h index
bd8ec30..e87423a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1855,6 +1855,29 @@ static inline struct eeh_dev
*pci_dev_to_eeh_dev(struct pci_dev *pdev) #endif
/**
+ * pci_walk_up_to_first_match - Generic upstream search function
+ * @pdev: starting PCI device to search
+ * @match: match function to call on each device (true = match)
+ * @last: last device examined prior to returned device
+ *
+ * Walk upstream from the given device, calling match() at each device.
+ * Returns the first device matching match(). If the root bus is
+reached
+ * without finding a match, return NULL. last returns the N-1 step in
+ * the search path.
+ */
+struct pci_dev *pci_walk_up_to_first_match(struct pci_dev *pdev,
+bool (*match)(struct pci_dev *),
+struct pci_dev **last);
+
+/**
+ * pci_is_pcie_bridge - Match a PCIe bridge device
+ * @pdev: device to test
+ *
+ * Return true if the given device is a PCIe bridge, false otherwise.
+ */
+bool pci_is_pcie_bridge(struct pci_dev *pdev);
+
+/**
* pci_find_upstream_pcie_bridge - find upstream PCIe-to-PCI bridge of a
device
* @pdev: the PCI device
*
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 1/2 v15] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
-Original Message- From: j...@8bytes.org [mailto:j...@8bytes.org] Sent: Thursday, May 02, 2013 3:46 PM To: Sethi Varun-B16395 Cc: iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux-ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-B08248; Wood Scott-B07421 Subject: Re: [PATCH 1/2 v15] iommu/fsl: Add additional iommu attributes required by the PAMU driver. On Tue, Apr 30, 2013 at 05:09:32PM +, Sethi Varun-B16395 wrote: Would you take this patchset for 3.10 merge? Not this time. The final patch came in very late and is pretty big too. For code of that size I would like to have a few weeks more testing in next and probably also a non-Freescale Reviewed-by. [Sethi Varun-B16395] I would request you and Alex Williamson to review the patch and provide a Reviewed-by. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 1/2 v15] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
Hi Joerg,
Would you take this patchset for 3.10 merge?
Regards
Varun
-Original Message-
From: Sethi Varun-B16395
Sent: Wednesday, April 24, 2013 5:06 PM
To: j...@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-B08248;
Wood Scott-B07421
Cc: Sethi Varun-B16395
Subject: [PATCH 1/2 v15] iommu/fsl: Add additional iommu attributes
required by the PAMU driver.
Added the following domain attributes for the FSL PAMU driver:
1. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
2. Added an attribute for enabling/disabling DMA to a particular
memory window.
3. Added domain attribute to check for PAMUV1 specific constraints.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
v15 changes:
- Moved fsl_pamu_stash.h under arch/powerpc/include/asm.
v14 changes:
- Add FSL prefix to PAMU attributes.
v13 changes:
- created a new file include/linux/fsl_pamu_stash.h for stash attributes.
v12 changes:
- Moved PAMU specifc stash ids and structures to PAMU header file.
- no change in v11.
- no change in v10.
arch/powerpc/include/asm/fsl_pamu_stash.h | 39
+
include/linux/iommu.h | 16
2 files changed, 55 insertions(+), 0 deletions(-) create mode 100644
arch/powerpc/include/asm/fsl_pamu_stash.h
diff --git a/arch/powerpc/include/asm/fsl_pamu_stash.h
b/arch/powerpc/include/asm/fsl_pamu_stash.h
new file mode 100644
index 000..caa1b21
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_pamu_stash.h
@@ -0,0 +1,39 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ */
+
+#ifndef __FSL_PAMU_STASH_H
+#define __FSL_PAMU_STASH_H
+
+/* cache stash targets */
+enum pamu_stash_target {
+ PAMU_ATTR_CACHE_L1 = 1,
+ PAMU_ATTR_CACHE_L2,
+ PAMU_ATTR_CACHE_L3,
+};
+
+/*
+ * This attribute allows configuring stashig specific parameters
+ * in the PAMU hardware.
+ */
+
+struct pamu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
+};
+
+#endif /* __FSL_PAMU_STASH_H */
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
2727810..313d17a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -57,10 +57,26 @@ struct iommu_domain {
#define IOMMU_CAP_CACHE_COHERENCY0x1
#define IOMMU_CAP_INTR_REMAP 0x2 /* isolates device intrs */
+/*
+ * Following constraints are specifc to FSL_PAMUV1:
+ * -aperture must be power of 2, and naturally aligned
+ * -number of windows must be power of 2, and address space size
+ * of each window is determined by aperture size / # of windows
+ * -the actual size of the mapped region of a window must be power
+ * of 2 starting with 4KB and physical address must be naturally
+ * aligned.
+ * DOMAIN_ATTR_FSL_PAMUV1 corresponds to the above mentioned contraints.
+ * The caller can invoke iommu_domain_get_attr to check if the
+underlying
+ * iommu implementation supports these constraints.
+ */
+
enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
DOMAIN_ATTR_PAGING,
DOMAIN_ATTR_WINDOWS,
+ DOMAIN_ATTR_FSL_PAMU_STASH,
+ DOMAIN_ATTR_FSL_PAMU_ENABLE,
+ DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_MAX,
};
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: RFC: vfio / iommu driver for hardware with no iommu
-Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel Sent: Wednesday, April 24, 2013 4:27 PM To: Yoder Stuart-B08248 Cc: iommu@lists.linux-foundation.org Subject: Re: RFC: vfio / iommu driver for hardware with no iommu On Tue, Apr 23, 2013 at 04:13:00PM +, Yoder Stuart-B08248 wrote: We're aware of the obvious limitations-- no protection, DMA'able memory must be physically contiguous and will have no iova-phy translation. But there are use cases where all OSes involved are trusted and customers can live with those limitations. Virtualization is used here not to sandbox untrusted code, but to consolidate multiple OSes. One of the major points of VFIO is to provide a userspace interface for hardware IOMMUs. So if you have a platform without an IOMMU why do you care about VFIO at all? Agreed, but vfio also provides a standardized interface for direct device assignment under KVM. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 1/3 v2] iommu: Move swap_pci_ref function to pci.h.
Thanks. -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel Sent: Tuesday, April 23, 2013 6:32 PM To: Sethi Varun-B16395 Cc: ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart- B08248; linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org Subject: Re: [PATCH 1/3 v2] iommu: Move swap_pci_ref function to pci.h. On Tue, Apr 23, 2013 at 10:05:24AM +0530, Varun Sethi wrote: +#ifndef __PCI_H +#define __PCI_H Using __PCI_H is not a wise choice, it has certainly a high risk of a collision. Anyway, I changed it to __IOMMU_PCI_H and applied the patch. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
-Original Message- From: Joerg Roedel [mailto:j...@8bytes.org] Sent: Tuesday, April 23, 2013 7:09 PM To: Sethi Varun-B16395 Cc: iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux-ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-B08248; Wood Scott-B07421 Subject: Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver. On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote: Added the following domain attributes for the FSL PAMU driver: 1. Added new iommu stash attribute, which allows setting of the LIODN specific stash id parameter through IOMMU API. 2. Added an attribute for enabling/disabling DMA to a particular memory window. 3. Added domain attribute to check for PAMUV1 specific constraints. Signed-off-by: Varun Sethi varun.se...@freescale.com --- v14 changes: - Add FSL prefix to PAMU attributes. v13 changes: - created a new file include/linux/fsl_pamu_stash.h for stash attributes. v12 changes: - Moved PAMU specifc stash ids and structures to PAMU header file. - no change in v11. - no change in v10. include/linux/fsl_pamu_stash.h | 39 +++ Isn't asm/ for your architecture a better place for that header? I think it's fine to have the header under linux, actually I also the intel-iommu header under linux. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: RFC: vfio / iommu driver for hardware with no iommu
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Alex Williamson
Sent: Tuesday, April 23, 2013 10:26 PM
To: Yoder Stuart-B08248
Cc: iommu@lists.linux-foundation.org
Subject: Re: RFC: vfio / iommu driver for hardware with no iommu
On Tue, 2013-04-23 at 16:13 +, Yoder Stuart-B08248 wrote:
Joerg/Alex,
We have embedded systems where we use QEMU/KVM and have the
requirement to do device assignment, but have no iommu. So we would
like to get vfio-pci working on systems like this.
We're aware of the obvious limitations-- no protection, DMA'able
memory must be physically contiguous and will have no iova-phy
translation. But there are use cases where all OSes involved are
trusted and customers can
live with those limitations. Virtualization is used
here not to sandbox untrusted code, but to consolidate multiple OSes.
We would like to get your feedback on the rough idea. There are two
parts-- iommu driver and vfio-pci.
1. iommu driver
First, we still need device groups created because vfio is based on
that, so we envision a 'dummy' iommu driver that implements only the
add/remove device ops. Something like:
static struct iommu_ops fsl_none_ops = {
.add_device = fsl_none_add_device,
.remove_device = fsl_none_remove_device,
};
int fsl_iommu_none_init()
{
int ret = 0;
ret = iommu_init_mempool();
if (ret)
return ret;
bus_set_iommu(platform_bus_type, fsl_none_ops);
bus_set_iommu(pci_bus_type, fsl_none_ops);
return ret;
}
2. vfio-pci
For vfio-pci, we would ideally like to keep user space mostly
unchanged. User space will have to follow the semantics of mapping
only physically contiguous chunks...and iova will equal phys.
So, we propose to implement a new vfio iommu type, called
VFIO_TYPE_NONE_IOMMU. This implements any needed vfio interfaces, but
there are no calls to the iommu layer...e.g. map_dma() is a noop.
Would like your feedback.
My first thought is that this really detracts from vfio and iommu groups
being a secure interface, so somehow this needs to be clearly an insecure
mode that requires an opt-in and maybe taints the kernel. Any notion of
unprivileged use needs to be blocked and it should test
CAP_COMPROMISE_KERNEL (or whatever it's called now) at critical access
points. We might even have interfaces exported that would allow this to
be an out-of-tree driver (worth a check).
I would guess that you would probably want to do all the iommu group
setup from the vfio fake-iommu driver. In other words, that driver both
creates the fake groups and provides the dummy iommu backend for vfio.
That would be a nice way to compartmentalize this as a vfio-noiommu-
special.
[Sethi Varun-B16395] Yes, we would be doing device group creation in the dummy
iommu driver
Would map/unmap really be no-ops? Seems like you still want to do page
pinning. Also, you're using fsl in the example above, but would such a
driver have any platform dependency? Thanks,
[Sethi Varun-B16395] map/unmap ioctls would be supported for pinning guest
pages. Yes, there would be a platform dependency for the driver.
-Varun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/3 v13] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, April 23, 2013 5:20 AM
To: Sethi Varun-B16395
Cc: j...@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-B08248;
Sethi Varun-B16395
Subject: Re: [PATCH 2/3 v13] iommu/fsl: Add additional iommu attributes
required by the PAMU driver.
On 04/22/2013 12:31:55 AM, Varun Sethi wrote:
Added the following domain attributes for the FSL PAMU driver:
1. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
2. Added an attribute for enabling/disabling DMA to a particular
memory window.
3. Added domain attribute to check for PAMUV1 specific constraints.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
v13 changes:
- created a new file include/linux/fsl_pamu_stash.h for stash
attributes.
v12 changes:
- Moved PAMU specifc stash ids and structures to PAMU header file.
- no change in v11.
- no change in v10.
include/linux/fsl_pamu_stash.h | 39
+++
include/linux/iommu.h | 16
2 files changed, 55 insertions(+), 0 deletions(-) create mode 100644
include/linux/fsl_pamu_stash.h
diff --git a/include/linux/fsl_pamu_stash.h
b/include/linux/fsl_pamu_stash.h new file mode 100644 index
000..caa1b21
--- /dev/null
+++ b/include/linux/fsl_pamu_stash.h
@@ -0,0 +1,39 @@
+/*
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License, version 2,
as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ */
+
+#ifndef __FSL_PAMU_STASH_H
+#define __FSL_PAMU_STASH_H
+
+/* cache stash targets */
+enum pamu_stash_target {
+ PAMU_ATTR_CACHE_L1 = 1,
+ PAMU_ATTR_CACHE_L2,
+ PAMU_ATTR_CACHE_L3,
+};
+
+/*
+ * This attribute allows configuring stashig specific parameters
+ * in the PAMU hardware.
+ */
+
+struct pamu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
+};
+
+#endif /* __FSL_PAMU_STASH_H */
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
2727810..c5dc2b9 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -57,10 +57,26 @@ struct iommu_domain {
#define IOMMU_CAP_CACHE_COHERENCY 0x1
#define IOMMU_CAP_INTR_REMAP 0x2 /* isolates device
intrs */
+/*
+ * Following constraints are specifc to PAMUV1:
FSL_PAMUV1
+ * -aperture must be power of 2, and naturally aligned
+ * -number of windows must be power of 2, and address space size
+ * of each window is determined by aperture size / # of windows
+ * -the actual size of the mapped region of a window must be power
+ * of 2 starting with 4KB and physical address must be naturally
+ * aligned.
+ * DOMAIN_ATTR_FSL_PAMUV1 corresponds to the above mentioned
contraints.
+ * The caller can invoke iommu_domain_get_attr to check if the
underlying
+ * iommu implementation supports these constraints.
+ */
+
enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
DOMAIN_ATTR_PAGING,
DOMAIN_ATTR_WINDOWS,
+ DOMAIN_ATTR_PAMU_STASH,
+ DOMAIN_ATTR_PAMU_ENABLE,
+ DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_MAX,
Please be consistent on whether PAMU gets an FSL_ namespace prefix
(I'd prefer that it does).
Submitted new version(v14) of the patch with updated attribute names.
-Varun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Wednesday, April 03, 2013 11:32 PM To: Joerg Roedel Cc: Sethi Varun-B16395; Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote: Cc'ing Alex Williamson Alex, can you please review the iommu-group part of this patch? Sure, it looks pretty reasonable. AIUI, all PCI devices are below some kind of host bridge that is either new and supports partitioning or old and doesn't. I don't know if that's a visibility or isolation requirement, perhaps PCI ACS-ish. In the new host bridge case, each device gets a group. This seems not to have any quirks for multifunction devices though. On AMD and Intel IOMMUs we test multifunction device ACS support to determine whether all the functions should be in the same group. Is there any reason to trust multifunction devices on PAMU? [Sethi Varun-B16395] In the case where we can partition endpoints we can distinguish transactions based on the bus,device,function number combination. This support is available in the PCIe controller (host bridge). I also find it curious what happens to the iommu group of the host bridge. In the partitionable case the host bridge group is removed, in the non-partitionable case the host bridge group becomes the group for the children, removing the host bridge. It's unique to PAMU so far that these host bridges are even in an iommu group (x86 only adds pci devices), but I don't see it as necessarily wrong leaving it in either scenario. Does it solve some problem to remove them from the groups? Thanks, [Sethi Varun-B16395] The PCIe controller isn't a partitionable entity, it would always be owned by the host. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Thursday, April 04, 2013 8:52 PM To: Sethi Varun-B16395 Cc: Joerg Roedel; Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On Thu, 2013-04-04 at 13:00 +, Sethi Varun-B16395 wrote: -Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Wednesday, April 03, 2013 11:32 PM To: Joerg Roedel Cc: Sethi Varun-B16395; Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote: Cc'ing Alex Williamson Alex, can you please review the iommu-group part of this patch? Sure, it looks pretty reasonable. AIUI, all PCI devices are below some kind of host bridge that is either new and supports partitioning or old and doesn't. I don't know if that's a visibility or isolation requirement, perhaps PCI ACS-ish. In the new host bridge case, each device gets a group. This seems not to have any quirks for multifunction devices though. On AMD and Intel IOMMUs we test multifunction device ACS support to determine whether all the functions should be in the same group. Is there any reason to trust multifunction devices on PAMU? [Sethi Varun-B16395] In the case where we can partition endpoints we can distinguish transactions based on the bus,device,function number combination. This support is available in the PCIe controller (host bridge). So can x86 IOMMUs, that's the visibility aspect of IOMMU groups. Visibility alone doesn't necessarily imply that a device is isolated though. A multifunction PCI device that doesn't expose ACS support may not isolate functions from each other. For example a peer-to-peer DMA between functions may not be translated by the upstream IOMMU. IOMMU groups should encompass both visibility and isolation. [Sethi Varun-B16395] We can isolate the DMA access to the host based on the to the pci bus,device,function number. I thought that was enough to put devices in to separate iommu groups. This is a PCIe controller property which allows us to partition PCIe devices. But, what I can understand from your point is that we also need to consider isolation at PCIe device level as well. I will check for the case of multifunction devices. I also find it curious what happens to the iommu group of the host bridge. In the partitionable case the host bridge group is removed, in the non-partitionable case the host bridge group becomes the group for the children, removing the host bridge. It's unique to PAMU so far that these host bridges are even in an iommu group (x86 only adds pci devices), but I don't see it as necessarily wrong leaving it in either scenario. Does it solve some problem to remove them from the groups? Thanks, [Sethi Varun-B16395] The PCIe controller isn't a partitionable entity, it would always be owned by the host. Ownership of a device shouldn't play into the group context. An IOMMU group should be defined by it's visibility and isolation from other devices. Whether the PCIe controller is allowed to be handed to userspace is a question for VFIO. [Sethi Varun-B16395] The problem is in the case, where we can't partition PCIe devices. PCIe devices share the same device group as the PCI controller. This becomes a problem while assigning the devices to the guest, as you are required to unbind all the PCIe devices including the controller from the host. PCIe controller can't be unbound from the host, so we simply delete the controller iommu_group. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Thursday, April 04, 2013 10:14 PM To: Sethi Varun-B16395 Cc: Joerg Roedel; Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On Thu, 2013-04-04 at 16:35 +, Sethi Varun-B16395 wrote: -Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Thursday, April 04, 2013 8:52 PM To: Sethi Varun-B16395 Cc: Joerg Roedel; Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On Thu, 2013-04-04 at 13:00 +, Sethi Varun-B16395 wrote: -Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Wednesday, April 03, 2013 11:32 PM To: Joerg Roedel Cc: Sethi Varun-B16395; Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote: Cc'ing Alex Williamson Alex, can you please review the iommu-group part of this patch? Sure, it looks pretty reasonable. AIUI, all PCI devices are below some kind of host bridge that is either new and supports partitioning or old and doesn't. I don't know if that's a visibility or isolation requirement, perhaps PCI ACS-ish. In the new host bridge case, each device gets a group. This seems not to have any quirks for multifunction devices though. On AMD and Intel IOMMUs we test multifunction device ACS support to determine whether all the functions should be in the same group. Is there any reason to trust multifunction devices on PAMU? [Sethi Varun-B16395] In the case where we can partition endpoints we can distinguish transactions based on the bus,device,function number combination. This support is available in the PCIe controller (host bridge). So can x86 IOMMUs, that's the visibility aspect of IOMMU groups. Visibility alone doesn't necessarily imply that a device is isolated though. A multifunction PCI device that doesn't expose ACS support may not isolate functions from each other. For example a peer-to-peer DMA between functions may not be translated by the upstream IOMMU. IOMMU groups should encompass both visibility and isolation. [Sethi Varun-B16395] We can isolate the DMA access to the host based on the to the pci bus,device,function number. The IOMMU can only isolate DMA that it can see. A multifunction device may never expose peer-to-peer DMA to the upstream device, it's implementation specific. The ACS flags allow that possibility to be controlled and prevented. I thought that was enough to put devices in to separate iommu groups. This is a PCIe controller property which allows us to partition PCIe devices. But, what I can understand from your point is that we also need to consider isolation at PCIe device level as well. I will check for the case of multifunction devices. I also find it curious what happens to the iommu group of the host bridge. In the partitionable case the host bridge group is removed, in the non-partitionable case the host bridge group becomes the group for the children, removing the host bridge. It's unique to PAMU so far that these host bridges are even in an iommu group (x86 only adds pci devices), but I don't see it as necessarily wrong leaving it in either scenario. Does it solve some problem to remove them from the groups? Thanks, [Sethi Varun-B16395] The PCIe controller isn't a partitionable entity, it would always be owned by the host. Ownership of a device shouldn't play into the group context. An IOMMU group should be defined by it's visibility and isolation from other devices. Whether the PCIe controller is allowed to be handed to userspace is a question for VFIO. [Sethi Varun-B16395] The problem is in the case, where we can't partition PCIe devices. PCIe devices share the same device group as the PCI controller. This becomes a problem while assigning the devices to the guest, as you are required to unbind all the PCIe devices including the controller from the host. PCIe controller can't be unbound from the host, so we simply delete
RE: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
-Original Message- From: Joerg Roedel [mailto:j...@8bytes.org] Sent: Tuesday, April 02, 2013 9:53 PM To: Sethi Varun-B16395 Cc: Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux- foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation. On Fri, Mar 29, 2013 at 01:23:57AM +0530, Varun Sethi wrote: This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Make iova dma_addr_t in the iommu_iova_to_phys API. 2. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. 3. Add window permission flags in the iommu_domain_window_enable API. 4. Add domain attributes for FSL PAMU driver. 5. PAMU driver and IOMMU API implementation. Okay, I am about to apply patches 1 and 3 to a new ppc/pamu branch in my tree. As a general question, how did you test the IOMMU driver and what will you do in the future to avoid regressions? I use a kernel module for testing the iommu_api support. The module allows for dynamic creation and deletion of iommu domains for the devices in the device tree. Also, the vfio support (under development) for Freescale SOCs with APMU hardware would depend on the PAMU driver. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 03, 2013 7:23 AM To: Timur Tabi Cc: Joerg Roedel; Sethi Varun-B16395; lkml; Kumar Gala; Yoder Stuart- B08248; iommu@lists.linux-foundation.org; Benjamin Herrenschmidt; linuxppc-...@lists.ozlabs.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On 04/02/2013 08:35:54 PM, Timur Tabi wrote: On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel j...@8bytes.org wrote: + panic(\n); A kernel panic seems like an over-reaction to an access violation. We have no way to determining what code caused the violation, so we can't just kill the process. I agree it seems like overkill, but what else should we do? Does the IOMMU layer have a way for the IOMMU driver to stop the device that caused the problem? At a minimum, log a message and continue. Probably turn off the LIODN, at least if it continues to be noisy (otherwise we could get stuck in an interrupt storm as you note). Possibly let the user know somehow, especially if it's a VFIO domain. [Sethi Varun-B16395] Can definitely log the message and disable the LIODN (to avoid an interrupt storm), but we definitely need a mechanism to inform vfio subsystem about the error. Also, disabling LIODN may not be a viable option with the new LIODN allocation scheme (where LIODN would be associated with a domain). Don't take down the whole kernel. It's not just overkill; it undermines VFIO's efforts to make it safe for users to control devices. Besides the device that caused the violation the system should still work, no? Not really. The PAMU was designed to add IOMMU support to legacy devices, which have no concept of an MMU. If the PAMU detects an access violation, there's no way for the device to recover, because it has no idea that a violation has occurred. It's going to keep on writing to bad data. I think that's only the case for posted writes (or devices which fail to take a hint and stop even after they see an I/O error). [Sethi Varun-B16395] Even in the case where the guest driver detects a failure, it may not be able to fix the problem without intervention from the VFIO subsystem. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
Kumar/Ben, Any comments? (Had checked with Ben (on IRC) sometime back, he was fine with this patch) Regards Varun -Original Message- From: Joerg Roedel [mailto:j...@8bytes.org] Sent: Tuesday, April 02, 2013 8:39 PM To: Sethi Varun-B16395 Cc: Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux- foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata On Fri, Mar 29, 2013 at 01:23:59AM +0530, Varun Sethi wrote: Add an iommu domain pointer to device (powerpc) archdata. Devices are attached to iommu domains and this pointer provides a mechanism to correlate between a device and the associated iommu domain. This field is set when a device is attached to a domain. Signed-off-by: Varun Sethi varun.se...@freescale.com This patch needs to be Acked by the PPC maintainers. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Tuesday, April 02, 2013 8:40 PM
To: Sethi Varun-B16395
Cc: Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-
foundation.org; linuxppc-...@lists.ozlabs.org; linux-
ker...@vger.kernel.org; ga...@kernel.crashing.org;
b...@kernel.crashing.org
Subject: Re: [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes
required by the PAMU driver.
On Fri, Mar 29, 2013 at 01:24:01AM +0530, Varun Sethi wrote:
+/* cache stash targets */
+enum stash_target {
+ IOMMU_ATTR_CACHE_L1 = 1,
+ IOMMU_ATTR_CACHE_L2,
+ IOMMU_ATTR_CACHE_L3,
+};
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
+};
+
I would prefer these PAMU specific enum and struct to be in a pamu-
specific iommu-header.
[Sethi Varun-B16395] But, these would be used by the IOMMU API users (e.g.
VFIO), they shouldn't depend on PAMU specific headers.
-Varun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 1/5 v10] iommu/fsl: Make iova u64 in the iommu_iova_to_phys API.
Because of the PAMU supported window sizes the iova can be 32bit value even
on 32 bit architectures. I see that we have the CONFIG_ARCH_DMA_ADDR_T_64BIT
config option enabled in our case, so dma_addr_t would be u64 in our case.
-Varun
-Original Message-
From: Don Dutile [mailto:ddut...@redhat.com]
Sent: Monday, March 25, 2013 8:38 PM
To: iommu@lists.linux-foundation.org
Cc: Sethi Varun-B16395
Subject: Re: [PATCH 1/5 v10] iommu/fsl: Make iova u64 in the
iommu_iova_to_phys API.
I agree that unsigned long was an improper choice for iova's, but why
aren't they dma_addr_t ? ... an iova is a dma-addr, just a 'virtual' one
wrt phys-addr.
On 03/22/2013 06:34 PM, Varun Sethi wrote:
This is required in case of PAMU, as it can support a window size of
up to 64G (even on 32bit).
Signed-off-by: Varun Sethivarun.se...@freescale.com
---
- no change in v10.
drivers/iommu/amd_iommu.c |2 +-
drivers/iommu/exynos-iommu.c |2 +-
drivers/iommu/intel-iommu.c|2 +-
drivers/iommu/iommu.c |3 +--
drivers/iommu/msm_iommu.c |2 +-
drivers/iommu/omap-iommu.c |2 +-
drivers/iommu/shmobile-iommu.c |2 +-
drivers/iommu/tegra-gart.c |2 +-
drivers/iommu/tegra-smmu.c |2 +-
include/linux/iommu.h |9 +++--
10 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 98f555d..42f6a71 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3412,7 +3412,7 @@ static size_t amd_iommu_unmap(struct iommu_domain
*dom, unsigned long iova,
}
static phys_addr_t amd_iommu_iova_to_phys(struct iommu_domain *dom,
- unsigned long iova)
+ u64 iova)
{
struct protection_domain *domain = dom-priv;
unsigned long offset_mask;
diff --git a/drivers/iommu/exynos-iommu.c
b/drivers/iommu/exynos-iommu.c index 238a3ca..541e81b 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1027,7 +1027,7 @@ done:
}
static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain
*domain,
- unsigned long iova)
+ u64 iova)
{
struct exynos_iommu_domain *priv = domain-priv;
unsigned long *entry;
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0099667..c9663ac 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4111,7 +4111,7 @@ static size_t intel_iommu_unmap(struct
iommu_domain *domain,
}
static phys_addr_t intel_iommu_iova_to_phys(struct iommu_domain
*domain,
- unsigned long iova)
+ u64 iova)
{
struct dmar_domain *dmar_domain = domain-priv;
struct dma_pte *pte;
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index
b972d43..39106ec 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -706,8 +706,7 @@ void iommu_detach_group(struct iommu_domain
*domain, struct iommu_group *group)
}
EXPORT_SYMBOL_GPL(iommu_detach_group);
-phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain,
- unsigned long iova)
+phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, u64 iova)
{
if (unlikely(domain-ops-iova_to_phys == NULL))
return 0;
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 6a8870a..fcd14a3 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -554,7 +554,7 @@ fail:
}
static phys_addr_t msm_iommu_iova_to_phys(struct iommu_domain
*domain,
- unsigned long va)
+ u64 va)
{
struct msm_priv *priv;
struct msm_iommu_drvdata *iommu_drvdata; diff --git
a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index
6ac02fa..102ae56 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1219,7 +1219,7 @@ static void omap_iommu_domain_destroy(struct
iommu_domain *domain)
}
static phys_addr_t omap_iommu_iova_to_phys(struct iommu_domain
*domain,
- unsigned long da)
+ u64 da)
{
struct omap_iommu_domain *omap_domain = domain-priv;
struct omap_iommu *oiommu = omap_domain-iommu_dev; diff --git
a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index b6e8b57..9216802 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -296,7 +296,7 @@ done:
}
static phys_addr_t shmobile_iommu_iova_to_phys(struct iommu_domain
*domain,
- unsigned long iova
RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Kumar Gala
Sent: Friday, March 15, 2013 1:50 AM
To: Sethi Varun-B16395
Cc: b...@kernel.crashing.org; linux-ker...@vger.kernel.org; Yoder Stuart-
B08248; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu
implementation.
On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote:
+/*
+ * Table of SVRs and the corresponding PORT_ID values.
+ *
+ * All future CoreNet-enabled SOCs will have this erratum fixed, so
+this table
+ * should never need to be updated. SVRs are guaranteed to be
+unique, so
+ * there is no worry that a future SOC will inadvertently have one of
+these
+ * values.
+ */
Maybe add to the comment about what port_id represents
[Sethi Varun-B16395] ok.
+static const struct {
+ u32 svr;
+ u32 port_id;
+} port_id_map[] = {
+ {0x82100010, 0xFF00}, /* P2040 1.0 */
+ {0x82100011, 0xFF00}, /* P2040 1.1 */
+ {0x82100110, 0xFF00}, /* P2041 1.0 */
+ {0x82100111, 0xFF00}, /* P2041 1.1 */
+ {0x82110310, 0xFF00}, /* P3041 1.0 */
+ {0x82110311, 0xFF00}, /* P3041 1.1 */
+ {0x82010020, 0xFFF8}, /* P4040 2.0 */
+ {0x8220, 0xFFF8}, /* P4080 2.0 */
+ {0x82210010, 0xFC00}, /* P5010 1.0 */
+ {0x82210020, 0xFC00}, /* P5010 2.0 */
+ {0x82200010, 0xFC00}, /* P5020 1.0 */
+ {0x82050010, 0xFF80}, /* P5021 1.0 */
+ {0x82040010, 0xFF80}, /* P5040 1.0 */
+};
+
+#define SVR_SECURITY 0x8 /* The Security (E) bit */
+
+static int __init fsl_pamu_probe(struct platform_device *pdev) {
+ void __iomem *pamu_regs = NULL;
+ struct ccsr_guts __iomem *guts_regs = NULL;
+ u32 pamubypenr, pamu_counter;
+ unsigned long pamu_reg_off;
+ unsigned long pamu_reg_base;
+ struct pamu_isr_data *data;
+ struct device_node *guts_node;
+ u64 size;
+ struct page *p;
+ int ret = 0;
+ int irq;
+ phys_addr_t ppaact_phys;
+ phys_addr_t spaact_phys;
+ phys_addr_t omt_phys;
+ size_t mem_size = 0;
+ unsigned int order = 0;
+ u32 csd_port_id = 0;
+ unsigned i;
+ /*
+* enumerate all PAMUs and allocate and setup PAMU tables
+* for each of them,
+* NOTE : All PAMUs share the same LIODN tables.
+*/
+
+ pamu_regs = of_iomap(pdev-dev.of_node, 0);
+ if (!pamu_regs) {
+ dev_err(pdev-dev, ioremap of PAMU node failed\n);
+ return -ENOMEM;
+ }
+ of_get_address(pdev-dev.of_node, 0, size, NULL);
+
+ irq = irq_of_parse_and_map(pdev-dev.of_node, 0);
+ if (irq == NO_IRQ) {
+ dev_warn(pdev-dev, no interrupts listed in PAMU node\n);
+ goto error;
+ }
+
+ data = kzalloc(sizeof(struct pamu_isr_data), GFP_KERNEL);
+ if (!data) {
+ iounmap(pamu_regs);
+ return -ENOMEM;
+ }
+ data-pamu_reg_base = pamu_regs;
+ data-count = size / PAMU_OFFSET;
+
+ /* The ISR needs access to the regs, so we won't iounmap them */
+ ret = request_irq(irq, pamu_av_isr, 0, pamu, data);
+ if (ret 0) {
+ dev_err(pdev-dev, error %i installing ISR for irq %i\n,
+ ret, irq);
+ goto error;
+ }
+
+ guts_node = of_find_compatible_node(NULL, NULL,
+ fsl,qoriq-device-config-1.0);
This doesn't work for T4 or B4 device trees.
[Sethi Varun-B16395]hmm I need to use the dcfg space for this.
+ if (!guts_node) {
+ dev_err(pdev-dev, could not find GUTS node %s\n,
+ pdev-dev.of_node-full_name);
+ ret = -ENODEV;
+ goto error;
+ }
+
+ guts_regs = of_iomap(guts_node, 0);
+ of_node_put(guts_node);
+ if (!guts_regs) {
+ dev_err(pdev-dev, ioremap of GUTS node failed\n);
+ ret = -ENODEV;
+ goto error;
+ }
+
+ /* read in the PAMU capability registers */
+ get_pamu_cap_values((unsigned long)pamu_regs);
+ /*
+* To simplify the allocation of a coherency domain, we allocate
the
+* PAACT and the OMT in the same memory buffer. Unfortunately,
this
+* wastes more memory compared to allocating the buffers
separately.
+*/
+ /* Determine how much memory we need */
+ mem_size = (PAGE_SIZE get_order(PAACT_SIZE)) +
+ (PAGE_SIZE get_order(SPAACT_SIZE)) +
+ (PAGE_SIZE get_order(OMT_SIZE));
+ order = get_order(mem_size);
+
+ p = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
+ if (!p) {
+ dev_err(pdev-dev, unable to allocate PAACT/SPAACT/OMT
block\n);
+ ret = -ENOMEM;
+ goto error
RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Friday, March 15, 2013 1:53 AM To: Sethi Varun-B16395 Cc: j...@8bytes.org; linux-ker...@vger.kernel.org; Yoder Stuart-B08248; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation. On Mar 14, 2013, at 3:20 PM, Kumar Gala wrote: On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote: +/* + * Table of SVRs and the corresponding PORT_ID values. + * + * All future CoreNet-enabled SOCs will have this erratum fixed, so +this table + * should never need to be updated. SVRs are guaranteed to be +unique, so + * there is no worry that a future SOC will inadvertently have one +of these + * values. + */ Maybe add to the comment about what port_id represents also, add reference to the erratum #/id/name [Sethi Varun-B16395] Ok. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Yoder Stuart-B08248 Sent: Friday, March 15, 2013 2:45 AM To: Kumar Gala; Sethi Varun-B16395 Cc: j...@8bytes.org; iommu@lists.linux-foundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; b...@kernel.crashing.org; Wood Scott-B07421 Subject: RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation. -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Thursday, March 14, 2013 3:20 PM To: Sethi Varun-B16395 Cc: j...@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; b...@kernel.crashing.org; Wood Scott-B07421; Yoder Stuart-B08248 Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation. On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote: +/* + * Table of SVRs and the corresponding PORT_ID values. + * + * All future CoreNet-enabled SOCs will have this erratum fixed, so +this table + * should never need to be updated. SVRs are guaranteed to be +unique, so + * there is no worry that a future SOC will inadvertently have one +of these + * values. + */ Maybe add to the comment about what port_id represents When you update the comment, I would also suggest identifying the specific errata here (A-004510) so that it's easy to reference back to the specific issue this code is fixing. [Sethi Varun-B16395] Ok -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
Hi Joerg, I have to post the next version of my patchset, should I base it on top of 3.9-rc1? By when would you move the iommu git tree to 3.9-rc1? Regards Varun -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Thursday, February 28, 2013 9:15 PM To: Sethi Varun-B16395 Cc: Joerg Roedel; Stuart Yoder; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott- B07421; Yoder Stuart-B08248 Subject: Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller. On Feb 27, 2013, at 4:56 AM, Sethi Varun-B16395 wrote: This patch is present in the next branch of linux ppc tree maintained by Kumar Gala. Following is the commit id: 52c5affc545053d37c0b05224bbf70f5336caa20 I am not sure if this would be part of 3.9-rc1. Regards varun This is now in Linus's tree so will be in 3.9-rc1 - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
-Original Message- From: Yoder Stuart-B08248 Sent: Friday, March 01, 2013 9:52 PM To: Alexey Kardashevskiy; Sethi Varun-B16395 Cc: Kumar Gala; Benjamin Herrenschmidt; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org list; linux-ker...@vger.kernel.org list; Wood Scott-B07421; Joerg Roedel; Paul Mackerras; David Gibson; Alex Williamson Subject: RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata. -Original Message- From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru] Sent: Friday, March 01, 2013 4:07 AM To: Sethi Varun-B16395 Cc: Kumar Gala; Benjamin Herrenschmidt; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org list; linux-ker...@vger.kernel.org list; Wood Scott-B07421; Yoder Stuart-B08248; Joerg Roedel; Paul Mackerras; David Gibson; Alex Williamson Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata. btw the device struct already has a pointer to its iommu_group, and the iommu_group struct itself has a pointer void *iommu_data which you could use for anything you want (iommu_group_get_iommudata(), iommu_group_set_iommudata()). By design you are expected to add iommu groups to a domain but not devices so I am not so sure that you really need a pointer to domain in the device struct. Well, at the lowest level the IOMMU API does attach devices to domains-- i.e. API attach_dev(). So, it seems to conceptually make sense to have a ptr from the device to the associated domain. When you implement attach_dev() you need to be able to see whether the device is already attached to a domain. Adding a couple of levels of indirection...from device to group to domain...doesn't seems to make things simpler or better IMHO. x86 keeps a pointer to the domain in device archdata and since there is a direct correlation between a device and domain I'd rather see it where this patch has it. As Stuart stated this allows us to maintain the device - domain relationship at the lowest level. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
Thanks for the clarification Alexey.
Kumar,
We are using this new field (for PAMU) to store the iommu domain (for iommu
API) information for a device.
Regards
Varun
-Original Message-
From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
Sent: Friday, March 01, 2013 6:55 AM
To: Kumar Gala
Cc: Sethi Varun-B16395; Benjamin Herrenschmidt; iommu@lists.linux-
foundation.org; linuxppc-...@lists.ozlabs.org list; linux-
ker...@vger.kernel.org list; Wood Scott-B07421; Yoder Stuart-B08248;
Joerg Roedel; Paul Mackerras; David Gibson; Alex Williamson
Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
pointer in archdata.
Hi!
On POWERNV we use only the part of IOMMU API which handles devices and
groups. We do not use IOMMU domains as VFIO containers do everything we
need for VFIO and we do not implement iommu_ops as it is not very
relevant to our architecture (does not give dma window properties, etc).
So your work does not overlap with my work :)
On 01/03/13 02:51, Kumar Gala wrote:
On Feb 27, 2013, at 6:04 AM, Sethi Varun-B16395 wrote:
Hi Kumar,Ben,
I am implementing the Freescale PAMU (IOMMU) driver using the Linux
IOMMU API. In this particular patch, I have added a new field to
dev_archdata structure to store the dma domain information.
This field is updated whenever we attach a device to an iommu domain.
Regards
Varun
Would be good to see if this overlaps with Alexey's work for IOMMU
driver for powernv.
- k
-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Wednesday, February 27, 2013 5:01 PM
To: Sethi Varun-B16395
Cc: iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org;
linux-ker...@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain
information pointer in archdata.
On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
Add a new field in the device (powerpc) archdata structure for
storing iommu domain information pointer. This pointer is stored
when the device is attached to a particular domain.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
- no change.
arch/powerpc/include/asm/device.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..6dc79fe 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,10 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+/* IOMMU domain information pointer. This would be set
+ * when this device is attached to an iommu_domain.
+ */
+void*iommu_domain;
Please Cc the PowerPC Maintainers on this, so that they can have a
look at it. This also must be put this into an #ifdef
CONFIG_IOMMU_API.
--
Alexey
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
This patch is present in the next branch of linux ppc tree maintained by Kumar Gala. Following is the commit id: 52c5affc545053d37c0b05224bbf70f5336caa20 I am not sure if this would be part of 3.9-rc1. Regards varun -Original Message- From: Joerg Roedel [mailto:j...@8bytes.org] Sent: Wednesday, February 27, 2013 4:15 PM To: Sethi Varun-B16395 Cc: Stuart Yoder; iommu@lists.linux-foundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248 Subject: Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller. On Tue, Feb 26, 2013 at 06:16:10AM +, Sethi Varun-B16395 wrote: This patch is not present in Joerg's tree and the add_device API in the PAMU driver requires this patch. Will this patch be part of v3.9-rc1? Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 0/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
Hi Joerg, Do you have any comments on the patch set. Regards Varun -Original Message- From: Sethi Varun-B16395 Sent: Monday, February 18, 2013 6:22 PM To: iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421; j...@8bytes.org; Yoder Stuart-B08248 Cc: Sethi Varun-B16395 Subject: [PATCH 0/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation. This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Store PCI controller platform device information in the PCI controller structure. 3. Add defines for FSL PCI controller BRR1 register. 4. Add window permission flags in the iommu_domain_window_enable API. 5. Add domain attributes for FSL PAMU driver. 6. PAMU driver and IOMMU API implementation. This patch set is based on the next branch of the iommu git tree maintained by Joerg. Varun Sethi (6): Store iommu domain information in the device structure. Store the platform device information corresponding to the pci controller. Added defines for the FSL PCI controller BRR1 register. Add window permission flags for iommu_domain_window_enable API. Add addtional attributes specific to the PAMU driver. FSL PAMU driver and IOMMU API implementation. arch/powerpc/include/asm/device.h |4 + arch/powerpc/include/asm/pci-bridge.h |4 + arch/powerpc/sysdev/fsl_pci.c |9 +- arch/powerpc/sysdev/fsl_pci.h |2 +- drivers/iommu/Kconfig |8 + drivers/iommu/Makefile|1 + drivers/iommu/fsl_pamu.c | 1260 + drivers/iommu/fsl_pamu.h | 398 +++ drivers/iommu/fsl_pamu_domain.c | 1135 + drivers/iommu/fsl_pamu_domain.h | 89 +++ drivers/iommu/iommu.c |5 +- include/linux/iommu.h | 40 +- 12 files changed, 2947 insertions(+), 8 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h -- 1.7.4.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
This patch is not present in Joerg's tree and the add_device API in the PAMU
driver requires this patch.
-Varun
-Original Message-
From: Stuart Yoder [mailto:b08...@gmail.com]
Sent: Tuesday, February 26, 2013 5:39 AM
To: Sethi Varun-B16395
Cc: iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org;
linux-ker...@vger.kernel.org; Wood Scott-B07421; Joerg Roedel; Yoder
Stuart-B08248
Subject: Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device
information corresponding to the pci controller.
This patch was submitted separately to linuxppc-dev (and was already
applied). You don't need it in this patch set, right?
Stuart
On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi varun.se...@freescale.com
wrote:
The pci controller structure has a provision to store the device
strcuture pointer of the corresponding platform device. Currently this
information is not stored during fsl pci controller initialization.
This information is required while dealing with iommu groups for pci
devices connected to the fsl pci controller. For the case where the
pci devices can't be paritioned, they would fall under the same device
group as the pci controller.
This patch stores the platform device information in the pci
controller structure during initialization.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/sysdev/fsl_pci.c |9 +++--
arch/powerpc/sysdev/fsl_pci.h |2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c
b/arch/powerpc/sysdev/fsl_pci.c index 92a5915..b393ae7 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -421,13 +421,16 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
}
}
-int __init fsl_add_bridge(struct device_node *dev, int is_primary)
+int __init fsl_add_bridge(struct platform_device *pdev, int
+is_primary)
{
int len;
struct pci_controller *hose;
struct resource rsrc;
const int *bus_range;
u8 hdr_type, progif;
+ struct device_node *dev;
+
+ dev = pdev-dev.of_node;
if (!of_device_is_available(dev)) {
pr_warning(%s: disabled\n, dev-full_name); @@
-453,6 +456,8 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
if (!hose)
return -ENOMEM;
+ /* set platform device as the parent */
+ hose-parent = pdev-dev;
hose-first_busno = bus_range ? bus_range[0] : 0x0;
hose-last_busno = bus_range ? bus_range[1] : 0xff;
@@ -880,7 +885,7 @@ static int fsl_pci_probe(struct platform_device
*pdev) #endif
node = pdev-dev.of_node;
- ret = fsl_add_bridge(node, fsl_pci_primary == node);
+ ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
#ifdef CONFIG_SWIOTLB
if (ret == 0) {
diff --git a/arch/powerpc/sysdev/fsl_pci.h
b/arch/powerpc/sysdev/fsl_pci.h index d078537..c495c00 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -91,7 +91,7 @@ struct ccsr_pci {
__be32 pex_err_cap_r3; /* 0x.e34 - PCIE error capture
register 0 */
};
-extern int fsl_add_bridge(struct device_node *dev, int is_primary);
+extern int fsl_add_bridge(struct platform_device *pdev, int
+is_primary);
extern void fsl_pcibios_fixup_bus(struct pci_bus *bus); extern int
mpc83xx_add_bridge(struct device_node *dev);
u64 fsl_pci_immrbar_base(struct pci_controller *hose);
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
-Original Message-
From: Craciun Diana Madalina-STFD002
Sent: Tuesday, February 19, 2013 9:30 PM
To: Sethi Varun-B16395
Cc: iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org;
linux-ker...@vger.kernel.org; Wood Scott-B07421; j...@8bytes.org; Yoder
Stuart-B08248
Subject: Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU
API implementation.
On 02/18/2013 02:52 PM, Varun Sethi wrote:
+/**
+ * pamu_get_ppaace() - Return the primary PACCE
+ * @liodn: liodn PAACT index for desired PAACE
+ *
+ * Returns the ppace pointer upon success else return
+ * null.
+ */
+static struct paace *pamu_get_ppaace(int liodn) {
+ if (!ppaact || liodn PAACE_NUMBER_ENTRIES) {
Shouldn't be liodn = PAACE_NUMBER_ENTRIES ?
Yes, will fix this.
-Varun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
-Original Message- From: Craciun Diana Madalina-STFD002 Sent: Tuesday, February 19, 2013 3:34 PM To: Sethi Varun-B16395 Cc: iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421; j...@8bytes.org; Yoder Stuart-B08248 Subject: Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation. On 02/18/2013 02:52 PM, Varun Sethi wrote: + +#define PAACE_TCEF_FORMAT0_8B 0x00 +#define PAACE_TCEF_FORMAT1_RSVD 0x01 + +#define PAACE_NUMBER_ENTRIES0x1FF Where is this number coming from? This is currently hard coded. We will not require these many entries once we implement the LIODN allocation scheme. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 4/5] iommu: Add domain window handling functions
Thanks Joerg. -Original Message- From: Joerg Roedel [mailto:j...@8bytes.org] Sent: Wednesday, February 06, 2013 3:56 PM To: Stuart Yoder Cc: Sethi Varun-B16395; iommu@lists.linux-foundation.org; linux- ker...@vger.kernel.org Subject: Re: [PATCH 4/5] iommu: Add domain window handling functions On Mon, Feb 04, 2013 at 05:31:51PM -0600, Stuart Yoder wrote: On Mon, Feb 4, 2013 at 12:56 PM, Joerg Roedel j...@8bytes.org wrote: Okay. So if your architecture supports sizes over 2^32 then size_t probably is already 64bits, right? No, on a 32-bit platform size_t would generally be 32-bits. But the PAMU is independent of that. I think we should just make it a u64. Okay, you can find the patches in the 'core' branch of the iommu-tree. They are also included in my next branch. You can use them now to base the PAMU patches on it. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute
Hi Joerg,
In case of PAMU, geometry would be meaningless without specifying the number of
subwindows. If the API user specifies a geometry but fails to specify the
number of required subwindows, we would assume a default (max supported) value,
which may be incorrect. It's going to be really ugly. I think we should add the
number of sub windows to the domain geometry. This parameter would be used in
case of a window based iommu. So, a separate set_window API wouldn't be
required.
We can still implement the get_windows API for getting the maximum number of
subwindows supported by the window based IOMMU.
Regards
Varun
-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Monday, February 04, 2013 6:49 PM
To: Sethi Varun-B16395; Stuart Yoder
Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; Joerg
Roedel
Subject: [PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute
This attribute can be used to set and get the number of subwindows on
IOMMUs that are window-based.
Signed-off-by: Joerg Roedel j...@8bytes.org
---
drivers/iommu/iommu.c | 33 ++---
include/linux/iommu.h |5 +
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index
0fdb7db..66402f7 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -891,6 +891,7 @@ int iommu_domain_get_attr(struct iommu_domain
*domain,
struct iommu_domain_geometry *geometry;
bool *paging;
int ret = 0;
+ u32 *count;
switch (attr) {
case DOMAIN_ATTR_GEOMETRY:
@@ -902,6 +903,15 @@ int iommu_domain_get_attr(struct iommu_domain
*domain,
paging = data;
*paging = (domain-ops-pgsize_bitmap != 0UL);
break;
+ case DOMAIN_ATTR_WINDOWS:
+ count = data;
+
+ if (domain-ops-domain_get_windows != NULL)
+ *count = domain-ops-domain_get_windows(domain);
+ else
+ ret = -ENODEV;
+
+ break;
default:
if (!domain-ops-domain_get_attr)
return -EINVAL;
@@ -916,9 +926,26 @@ EXPORT_SYMBOL_GPL(iommu_domain_get_attr);
int iommu_domain_set_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
{
- if (!domain-ops-domain_set_attr)
- return -EINVAL;
+ int ret = 0;
+ u32 *count;
+
+ switch (attr) {
+ case DOMAIN_ATTR_WINDOWS:
+ count = data;
+
+ if (domain-ops-domain_set_windows != NULL)
+ ret = domain-ops-domain_set_windows(domain, *count);
+ else
+ ret = -ENODEV;
- return domain-ops-domain_set_attr(domain, attr, data);
+ break;
+ default:
+ if (domain-ops-domain_set_attr == NULL)
+ return -EINVAL;
+
+ ret = domain-ops-domain_set_attr(domain, attr, data);
+ }
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
0cba2d8..8330df1 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -60,6 +60,7 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
DOMAIN_ATTR_PAGING,
+ DOMAIN_ATTR_WINDOWS,
DOMAIN_ATTR_MAX,
};
@@ -106,6 +107,10 @@ struct iommu_ops {
int (*domain_window_enable)(struct iommu_domain *domain, u32
wnd_nr,
phys_addr_t paddr, size_t size);
void (*domain_window_disable)(struct iommu_domain *domain, u32
wnd_nr);
+ /* Set the numer of window per domain */
+ int (*domain_set_windows)(struct iommu_domain *domain, u32
w_count);
+ /* Get the numer of window per domain */
+ u32 (*domain_get_windows)(struct iommu_domain *domain);
unsigned long pgsize_bitmap;
};
--
1.7.9.5
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute
DOMAIN_ATTR_PAMU_ENABLE is required to enable a particular DMA window. My point is about the domain geometry, which is incomplete in case of PAMU without the number of subwindows. Geometry parameters are used for initializing the PAMU window settings. Individual subwindows can only be enabled, once the PAMU window has been initialized using the geometry settings. Regards Varun -Original Message- From: Joerg Roedel [mailto:j...@8bytes.org] Sent: Tuesday, February 05, 2013 4:12 PM To: Sethi Varun-B16395 Cc: Stuart Yoder; iommu@lists.linux-foundation.org; linux- ker...@vger.kernel.org; Wood Scott-B07421 Subject: Re: [PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute Hi, On Tue, Feb 05, 2013 at 09:14:40AM +, Sethi Varun-B16395 wrote: In case of PAMU, geometry would be meaningless without specifying the number of subwindows. If the API user specifies a geometry but fails to specify the number of required subwindows, we would assume a default (max supported) value, which may be incorrect. It's going to be really ugly. I think we should add the number of sub windows to the domain geometry. This parameter would be used in case of a window based iommu. So, a separate set_window API wouldn't be required. I think this can all be implemented with the interface proposed here together with a PAMU-specific DOMAIN_ATTR_PAMU_ENABLE attribute. Stuart outlined in his RFC mail how this can be done. I don't consider this ugly, it is rather a clean tradeoff between putting functionality into the generic part of the IOMMU-API and putting it into the PAMU specific part. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute
-Original Message- From: Joerg Roedel [mailto:j...@8bytes.org] Sent: Tuesday, February 05, 2013 6:36 PM To: Sethi Varun-B16395 Cc: Stuart Yoder; iommu@lists.linux-foundation.org; linux- ker...@vger.kernel.org; Wood Scott-B07421 Subject: Re: [PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute On Tue, Feb 05, 2013 at 10:52:03AM +, Sethi Varun-B16395 wrote: DOMAIN_ATTR_PAMU_ENABLE is required to enable a particular DMA window. My point is about the domain geometry, which is incomplete in case of PAMU without the number of subwindows. Geometry parameters are used for initializing the PAMU window settings. Individual subwindows can only be enabled, once the PAMU window has been initialized using the geometry settings. I understand that. What you do is: /* Set geometry */ set_attr(domain, DOMAIN_ATTR_GEOMETRY); /* Set number of PAMU subwindows */ set_attr(domain, DOMAIN_ATTR_WINDOWS); /* Commit changes to hardware and enable the window */ set_attr(domain, DOMAIN_ATTR_PAMU_ENABLE); And I don't see any problem with that. The domain_attr interface was introduced to cope with device specifics, we don't change global interface data structures for that. [Sethi Varun-B16395] But, then it would be mandatory to set the DOMAIN_ATTR_WINDOWS attribute in case of PAMU. I guess that it would be implementation specific. I am fine with the API. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 4/4] iommu: Add domain window handling functions
-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Thursday, January 31, 2013 3:14 AM
To: Sethi Varun-B16395
Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; Joerg
Roedel
Subject: [PATCH 4/4] iommu: Add domain window handling functions
Add the iommu_domain_wnd_enable() and iommu_domain_wnd_disable()
functions to the IOMMU-API. These functions will be used to setup domains
that are based on subwindows and not on paging.
Signed-off-by: Joerg Roedel j...@8bytes.org
---
drivers/iommu/iommu.c | 20
include/linux/iommu.h | 18 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index
ab9dafd..55ae3bf 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -852,6 +852,26 @@ size_t iommu_unmap(struct iommu_domain *domain,
unsigned long iova, size_t size) } EXPORT_SYMBOL_GPL(iommu_unmap);
+
+int iommu_domain_wnd_enable(struct iommu_domain *domain, u32 window,
+ unsigned long offset, size_t size) {
+ if (unlikely(domain-ops-domain_wnd_enable == NULL))
+ return -ENODEV;
+
+ return domain-ops-domain_wnd_enable(domain, window, offset,
size); }
+EXPORT_SYMBOL_GPL(iommu_domain_wnd_enable);
+
+void iommu_domain_wnd_disable(struct iommu_domain *domain, u32 window)
+{
+ if (unlikely(domain-ops-domain_wnd_disable == NULL))
+ return;
+
+ return domain-ops-domain_wnd_disable(domain, window); }
+EXPORT_SYMBOL_GPL(iommu_domain_wnd_disable);
+
static int __init iommu_init(void)
{
iommu_group_kset = kset_create_and_add(iommu_groups,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
26066f5..f01657e 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -90,6 +90,9 @@ struct iommu_ops {
phys_addr_t paddr, size_t size, int prot);
size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
size_t size);
+ int (*domain_wnd_enable)(struct iommu_domain *domain, u32 window,
+unsigned long offset, size_t size);
+ void (*domain_wnd_disable)(struct iommu_domain *domain, u32
window);
phys_addr_t (*iova_to_phys)(struct iommu_domain *domain,
unsigned long iova);
int (*domain_has_cap)(struct iommu_domain *domain, @@ -123,6 +126,9
@@ extern int iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t size, int prot); extern
size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova,
size_t size);
+extern int iommu_domain_wnd_enable(struct iommu_domain *domain, u32
window,
+unsigned long offset, size_t size); extern
void
+iommu_domain_wnd_disable(struct iommu_domain *domain, u32 window);
extern phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain,
unsigned long iova);
extern int iommu_domain_has_cap(struct iommu_domain *domain, @@ -240,6
+246,18 @@ static inline int iommu_unmap(struct iommu_domain *domain,
unsigned long iova,
return -ENODEV;
}
+static inline int iommu_domain_wnd_enable(struct iommu_domain *domain,
+ u32 window, unsigned long offset,
+ size_t size)
+{
+ return -ENODEV;
+}
+
+static inline void iommu_domain_wnd_disable(struct iommu_domain *domain,
+ u32 window)
+{
+}
+
static inline phys_addr_t iommu_iova_to_phys(struct iommu_domain
*domain,
unsigned long iova)
{
We would need a corresponding physical address in the iommu_domain_wnd_enable
call. The sub windows can point to physically discontiguous locations. Also,
although we support partial mappings where the sub window size
geometry_size/max_sub_windows, but the mapping would always start from the sub
window base (sub window base address would be aligned to (geometry
size)/max_sub_windows). The user of the API would have to ensure that the iova
is aligned to the max sub window size. So, offset is not relevant in our case
as it would always be zero. The size should be u64 in order to accommodate
window sizes supported by PAMU.
int iommu_domain_wnd_enable(struct iommu_domain *domain, u32 window,
phys_addr_t paddr, u64 size)
We need a mechanism to determine the maximum number of subwindows supported by
PAMU. How about representing it in the iommu_domain structure:
struct iommu_domain {
struct iommu_ops *ops;
void *priv;
iommu_fault_handler_t handler;
void *handler_token;
struct iommu_domain_geometry geometry;
u32 max_sub_windows; - maximum number of sub windows supported by
the hardware.
}
Also, we would need to set the number
RE: [RFC] drivers: iommu: Use of add_device()/remove_device() outside of IOMMU groups
-Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Damian Hobson-Garcia Sent: Thursday, January 17, 2013 8:51 AM To: Alex Williamson Cc: h...@igel.co.jp; iommu@lists.linux-foundation.org; dw...@infradead.org; laurent.pinch...@ideasonboard.com Subject: Re: [RFC] drivers: iommu: Use of add_device()/remove_device() outside of IOMMU groups I mistakenly sent this with the tag [PATCH] when it should have been [RFC]. Updated with this reply. Hi Alex, On 2013/01/17 6:47, Alex Williamson wrote: On Tue, 2013-01-15 at 19:10 +0900, Damian Hobson-Garcia wrote: We've recently been thinking about the best way to attach platform devices in an IOMMU in a generic way without having to have every platform device register itself at probe time. We've seen that at least on the tegra IOMMU, using the platform_bus notifier seems like a viable option (http://lists.linuxfoundation.org/pipermail/iommu/2012-December/00495 4.html). We also noticed that the IOMMU ops add_device() function is called (indirectly) from a similar bus notifier and we're thinking that using the bus notifier in the common code would be better than us rolling our own to do basically the same thing. The problem, however, is that add_device() seems to be intended for use with IOMMU groups. i.e. After calling add_device() on a device that is should be in a group, dev-iommu_group should have some meaningful value. I think though, that if the IOMMU groups requirement can be removed, it should be more versatile. I believe that removing the IOMMU groups dependency can be achieved with the patch below. Currently the intel-iommu seems to be the only implementation using these callbacks. What stops you from creating a single iommu_group and adding all device to it? Thanks, Alex Thanks for your comment. Nothing stops me, but putting everything in one group doesn't really add any benefit over not using groups at all, does it? It seems like its just adding more complexity(i.e code) to the driver without adding any additional functionality. Do you intend to use vfio? That's the specific objective of creating iommu groups. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
Hi Joerg, It's been a while since I submitted this patch. I have tried to address your comments regarding the subwindow attribute. I would really appreciate if I can get some feedback on this patch. Regards Varun -Original Message- From: Sethi Varun-B16395 Sent: Friday, December 21, 2012 7:17 AM To: 'Joerg Roedel' Cc: Sethi Varun-B16395; joerg.roe...@amd.com; iommu@lists.linux- foundation.org; linuxppc-...@lists.ozlabs.org; linux- ker...@vger.kernel.org; Tabi Timur-B04825; Wood Scott-B07421 Subject: RE: [PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API implementation. ping!! -Original Message- From: Sethi Varun-B16395 Sent: Friday, December 14, 2012 7:22 PM To: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Tabi Timur-B04825; Wood Scott-B07421 Cc: Sethi Varun-B16395 Subject: [PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API implementation. This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Add PAMU bypass enable register to the ccsr_guts structure. 3. Addition of domain attributes required by the PAMU driver IOMMU API. 4. PAMU driver and IOMMU API implementation. This patch set is based on the next branch of the iommu git tree maintained by Joerg. Varun Sethi (4): store iommu domain info in device arch data. add pamu bypass enable register to guts. Add iommu attributes for PAMU FSL PAMU driver. arch/powerpc/include/asm/device.h |4 + arch/powerpc/include/asm/fsl_guts.h |4 +- drivers/iommu/Kconfig |8 + drivers/iommu/Makefile |1 + drivers/iommu/fsl_pamu.c| 1152 +++ drivers/iommu/fsl_pamu.h| 398 drivers/iommu/fsl_pamu_domain.c | 1033 +++ drivers/iommu/fsl_pamu_domain.h | 96 +++ include/linux/iommu.h | 49 ++ 9 files changed, 2744 insertions(+), 1 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h -- 1.7.4.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
ping!! -Original Message- From: Sethi Varun-B16395 Sent: Friday, December 14, 2012 7:22 PM To: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Tabi Timur-B04825; Wood Scott-B07421 Cc: Sethi Varun-B16395 Subject: [PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API implementation. This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Add PAMU bypass enable register to the ccsr_guts structure. 3. Addition of domain attributes required by the PAMU driver IOMMU API. 4. PAMU driver and IOMMU API implementation. This patch set is based on the next branch of the iommu git tree maintained by Joerg. Varun Sethi (4): store iommu domain info in device arch data. add pamu bypass enable register to guts. Add iommu attributes for PAMU FSL PAMU driver. arch/powerpc/include/asm/device.h |4 + arch/powerpc/include/asm/fsl_guts.h |4 +- drivers/iommu/Kconfig |8 + drivers/iommu/Makefile |1 + drivers/iommu/fsl_pamu.c| 1152 +++ drivers/iommu/fsl_pamu.h| 398 drivers/iommu/fsl_pamu_domain.c | 1033 +++ drivers/iommu/fsl_pamu_domain.h | 96 +++ include/linux/iommu.h | 49 ++ 9 files changed, 2744 insertions(+), 1 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h -- 1.7.4.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, December 04, 2012 11:53 PM To: Sethi Varun-B16395 Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote: -Original Message- From: Wood Scott-B07421 Sent: Monday, December 03, 2012 10:34 PM To: Sethi Varun-B16395 Cc: Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux- foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote: -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel Sent: Sunday, December 02, 2012 7:33 PM To: Sethi Varun-B16395 Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. Hmm, we need to work out a good abstraction for this. On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote: Added the following domain attributes required by FSL PAMU driver: 1. Subwindows field added to the iommu domain geometry attribute. Are the Subwindows mapped with full size or do you map only parts of the subwindows? [Sethi Varun-B16395] It's possible to map a part of the subwindow i.e. size of the mapping can be less than the sub window size. +* This attribute indicates number of DMA subwindows supported by +* the geometry. If there is a single window that maps the entire +* geometry, attribute must be set to 1. A value of 0 implies +* that this mechanism is not used at all(normal paging is used). +* Value other than* 0 or 1 indicates the actual number of +* subwindows. +*/ This semantic is ugly, how about a feature detection mechanism? [Sethi Varun-B16395] A feature mechanism to query the type of IOMMU? A feature mechanism to determine whether this subwindow mechanism is available, and what the limits are. So, we use the IOMMU capability interface to find out if IOMMU supports sub windows or not, right? But still number of sub windows would be specified as a part of the geometry and the valid value for sub windows would 0,1 or actual number of sub windows. How does a user of the interface find out what values are possible for the actual number of subwindows? How does a user of the interface find out whether there are any limitations on specifying a value of zero (in the case of PAMU, that would be a maximum 1 MiB naturally-aligned aperture to support arbitrary 4KiB mappings)? How about if we say that the default value for subwindows is zero and this what you get when you read the geometry (iommu_get_attr) after initializing the domain? In that case the user would know that implication of setting subwindows to zero with respect to the aperture size. Also, should we introduce an additional API like iommu_check_attr, which the user can use to validate the attribute value. For example in case of geometry, the user can fill up the structure and pass it to the iommu driver in order to verify the aperture and subwindows field. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, December 11, 2012 6:31 AM To: Sethi Varun-B16395 Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, December 04, 2012 11:53 PM To: Sethi Varun-B16395 Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote: -Original Message- From: Wood Scott-B07421 Sent: Monday, December 03, 2012 10:34 PM To: Sethi Varun-B16395 Cc: Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux- foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote: -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel Sent: Sunday, December 02, 2012 7:33 PM To: Sethi Varun-B16395 Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. Hmm, we need to work out a good abstraction for this. On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote: Added the following domain attributes required by FSL PAMU driver: 1. Subwindows field added to the iommu domain geometry attribute. Are the Subwindows mapped with full size or do you map only parts of the subwindows? [Sethi Varun-B16395] It's possible to map a part of the subwindow i.e. size of the mapping can be less than the sub window size. +* This attribute indicates number of DMA subwindows supported by +* the geometry. If there is a single window that maps the entire +* geometry, attribute must be set to 1. A value of 0 implies +* that this mechanism is not used at all(normal paging is used). +* Value other than* 0 or 1 indicates the actual number of +* subwindows. +*/ This semantic is ugly, how about a feature detection mechanism? [Sethi Varun-B16395] A feature mechanism to query the type of IOMMU? A feature mechanism to determine whether this subwindow mechanism is available, and what the limits are. So, we use the IOMMU capability interface to find out if IOMMU supports sub windows or not, right? But still number of sub windows would be specified as a part of the geometry and the valid value for sub windows would 0,1 or actual number of sub windows. How does a user of the interface find out what values are possible for the actual number of subwindows? How does a user of the interface find out whether there are any limitations on specifying a value of zero (in the case of PAMU, that would be a maximum 1 MiB naturally-aligned aperture to support arbitrary 4KiB mappings)? How about if we say that the default value for subwindows is zero and this what you get when you read the geometry (iommu_get_attr) after initializing the domain? In that case the user would know that implication of setting subwindows to zero with respect to the aperture size. So it would default to the maximum aperture size possible with no subwindows? That might be OK, though is there a way to reset the domain later on to get back to that informational state? [Sethi Varun-B16395] Yes, that can be done via iommu_set_attr API. How about finding out the maximum number of subwindows? [Sethi Varun-B16395] We can introduce an API to determine the permissible range of values for an attribute, but it may be redundant for other IOMMU implementations. For the IOMMU implementations where geometry is just a read only attribute, iommu_get_attr returns the set of permissible values. I think it would be better if we can add a read only field (for the users) max_subwindows to the geometry. -Varun ___ iommu mailing
RE: [PATCH 4/4 v6] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
-Original Message- From: Tabi Timur-B04825 Sent: Tuesday, December 04, 2012 1:33 AM To: Sethi Varun-B16395 Cc: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421 Subject: Re: [PATCH 4/4 v6] iommu/fsl: Freescale PAMU driver and IOMMU API implementation. Varun Sethi wrote: + out_be32(pamu_regs-ppbah, ((u64)ppaact_phys) 32); + out_be32(pamu_regs-ppbal, ppaact_phys); + ppaact_phys = ppaact_phys + PAACT_SIZE; + out_be32(pamu_regs-pplah, ((u64)ppaact_phys) 32); + out_be32(pamu_regs-pplal, ppaact_phys); Instead of ((u64)ppaact_phys) 32, use upper_32_bits() and lower_32_bits(). +#define PAACE_NUMBER_ENTRIES0xFF This is going to break with large LIODNs. Instead of hard-coding the size of the PPAACT, you need to scan the device tree for the largest LIODN, and make the array dynamically sized. This would in any case change with the new LIODN allocation scheme. I intend on introducing the new scheme as a separate patch. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
-Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel Sent: Sunday, December 02, 2012 7:33 PM To: Sethi Varun-B16395 Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. Hmm, we need to work out a good abstraction for this. On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote: Added the following domain attributes required by FSL PAMU driver: 1. Subwindows field added to the iommu domain geometry attribute. Are the Subwindows mapped with full size or do you map only parts of the subwindows? [Sethi Varun-B16395] It's possible to map a part of the subwindow i.e. size of the mapping can be less than the sub window size. +* This attribute indicates number of DMA subwindows supported by +* the geometry. If there is a single window that maps the entire +* geometry, attribute must be set to 1. A value of 0 implies +* that this mechanism is not used at all(normal paging is used). +* Value other than* 0 or 1 indicates the actual number of +* subwindows. +*/ This semantic is ugly, how about a feature detection mechanism? [Sethi Varun-B16395] A feature mechanism to query the type of IOMMU? -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
Ping!!
-Original Message-
From: Sethi Varun-B16395
Sent: Monday, November 26, 2012 10:55 AM
To: joerg.roe...@amd.com
Cc: Sethi Varun-B16395; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421;
Tabi Timur-B04825
Subject: RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes
required by fsl PAMU driver.
Hi Joerg,
Any comments? Can we apply this patch?
Regards
Varun
-Original Message-
From: Sethi Varun-B16395
Sent: Tuesday, November 20, 2012 7:25 PM
To: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421;
Tabi Timur-B04825
Cc: Sethi Varun-B16395
Subject: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes
required by fsl PAMU driver.
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
changes in v5:
- Updated description of the subwindows field.
changes in v4:
- Updated comment explaining subwindows(as mentioned by Scott).
change in v3:
-renamed the stash attribute targets
include/linux/iommu.h | 43
+++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
f3b99e1..7ca1cda 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,41 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be mapped */
dma_addr_t aperture_end; /* Last address that can be mapped
*/
bool force_aperture; /* DMA only allowed in mappable range?
*/
+
+ /*
+* A geometry mapping can be created in one of the following ways
+* for an IOMMU:
+* 1. A single contiguous window
+* 2. Through arbritary paging throughout the aperture.
+* 3. Using multiple subwindows
+*
+* In absence of arbritary paging, subwindows allow for supporting
+* physically discontiguous mappings.
+*
+* This attribute indicates number of DMA subwindows supported by
+* the geometry. If there is a single window that maps the entire
+* geometry, attribute must be set to 1. A value of 0 implies
+* that this mechanism is not used at all(normal paging is used).
+* Value other than* 0 or 1 indicates the actual number of
+* subwindows.
+*/
+ u32 subwindows;
+};
+
+/* cache stash targets */
+#define IOMMU_ATTR_CACHE_L1 1
+#define IOMMU_ATTR_CACHE_L2 2
+#define IOMMU_ATTR_CACHE_L3 3
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
};
struct iommu_domain {
@@ -60,6 +95,14 @@ struct iommu_domain { enum iommu_attr {
DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ /* Set the IOMMU hardware stashing
+* parameters.
+*/
+ DOMAIN_ATTR_STASH,
+ /* Explicity enable/disable DMA for a
+ * particular memory window.
+ */
+ DOMAIN_ATTR_ENABLE,
};
#ifdef CONFIG_IOMMU_API
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
Hi Joerg,
Any comments? Can we apply this patch?
Regards
Varun
-Original Message-
From: Sethi Varun-B16395
Sent: Tuesday, November 20, 2012 7:25 PM
To: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421;
Tabi Timur-B04825
Cc: Sethi Varun-B16395
Subject: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required
by fsl PAMU driver.
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
changes in v5:
- Updated description of the subwindows field.
changes in v4:
- Updated comment explaining subwindows(as mentioned by Scott).
change in v3:
-renamed the stash attribute targets
include/linux/iommu.h | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
f3b99e1..7ca1cda 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,41 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be mapped
*/
dma_addr_t aperture_end; /* Last address that can be mapped
*/
bool force_aperture; /* DMA only allowed in mappable range?
*/
+
+ /*
+ * A geometry mapping can be created in one of the following ways
+ * for an IOMMU:
+ * 1. A single contiguous window
+ * 2. Through arbritary paging throughout the aperture.
+ * 3. Using multiple subwindows
+ *
+ * In absence of arbritary paging, subwindows allow for supporting
+ * physically discontiguous mappings.
+ *
+ * This attribute indicates number of DMA subwindows supported by
+ * the geometry. If there is a single window that maps the entire
+ * geometry, attribute must be set to 1. A value of 0 implies
+ * that this mechanism is not used at all(normal paging is used).
+ * Value other than* 0 or 1 indicates the actual number of
+ * subwindows.
+ */
+ u32 subwindows;
+};
+
+/* cache stash targets */
+#define IOMMU_ATTR_CACHE_L1 1
+#define IOMMU_ATTR_CACHE_L2 2
+#define IOMMU_ATTR_CACHE_L3 3
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
};
struct iommu_domain {
@@ -60,6 +95,14 @@ struct iommu_domain { enum iommu_attr {
DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ /* Set the IOMMU hardware stashing
+ * parameters.
+ */
+ DOMAIN_ATTR_STASH,
+ /* Explicity enable/disable DMA for a
+ * particular memory window.
+ */
+ DOMAIN_ATTR_ENABLE,
};
#ifdef CONFIG_IOMMU_API
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer in archdata.
Hi Kumar,
Can you please apply this patch.
Regards
Varun
-Original Message-
From: Sethi Varun-B16395
Sent: Tuesday, November 20, 2012 7:25 PM
To: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood Scott-B07421;
Tabi Timur-B04825
Cc: Sethi Varun-B16395
Subject: [PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer
in archdata.
Add a new field in the device (powerpc) archdata structure for storing
iommu domain information pointer. This pointer is stored when the device
is attached to a particular domain.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/include/asm/device.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..6dc79fe 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,10 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+ /* IOMMU domain information pointer. This would be set
+ * when this device is attached to an iommu_domain.
+ */
+ void*iommu_domain;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
-Original Message-
From: Tabi Timur-B04825
Sent: Tuesday, October 23, 2012 2:48 AM
To: Sethi Varun-B16395
Cc: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU
API implementation.
On Wed, Oct 17, 2012 at 12:32 PM, Varun Sethi varun.se...@freescale.com
wrote:
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
Copyright 2012 Freescale Semiconductor, Inc.
[Sethi Varun-B16395] Have followed similar convention elsewhere i.e. added (C).
+ *
+ */
+
+#include linux/init.h
+#include linux/iommu.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/types.h
+#include linux/mm.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/of_platform.h
+#include linux/bootmem.h
+#include linux/genalloc.h
+#include asm/io.h
+#include asm/bitops.h
+
+#include fsl_pamu.h
+
+/* PAMU bypass enbale register contains control bits for
+ * enabling bypass mode on each PAMU.
+ */
/*
* Linux multi-line comments
* look like this.
*/
+#define PAMUBYPENR 0x604
Update struct ccsr_guts instead.
http://patchwork.ozlabs.org/patch/141649/
[Sethi Varun-B16395] Ok.
+
+/* define indexes for each operation mapping scenario */
+#define OMI_QMAN0x00
+#define OMI_FMAN0x01
+#define OMI_QMAN_PRIV 0x02
+#define OMI_CAAM0x03
+
+static paace_t *ppaact;
+static paace_t *spaact;
+static struct ome *omt;
+unsigned int max_subwindow_count;
+
+struct gen_pool *spaace_pool;
+
+static paace_t *pamu_get_ppaace(int liodn) {
+ if (!ppaact) {
+ pr_err(PPAACT doesn't exist\n);
pr_err(fsl-pamu: PPAACT has not been initialized\n);
Make sure ALL pr_xxx() messages in this file start with fsl-pamu:
+ return NULL;
+ }
+
+ return ppaact[liodn];
Bounds checking?
[Sethi Varun-B16395] Ok.
+}
+
+/** Sets validation bit of PACCE
+ *
+ * @parm[in] liodn PAACT index for desired PAACE
+ *
+ * @return Returns 0 upon success else error code 0 returned */
+int pamu_enable_liodn(int liodn) {
+ paace_t *ppaace;
+
+ ppaace = pamu_get_ppaace(liodn);
+ if (!ppaace)
+ return -ENOENT;
error message?
[Sethi Varun-B16395] Have error messages at places from where the function is
invoked.
+
+ if (!get_bf(ppaace-addr_bitfields, PPAACE_AF_WSE)) {
+ pr_err(liodn %d not configured\n, liodn);
+ return -EINVAL;
+ }
+
+ /* Ensure that all other stores to the ppaace complete first */
+ mb();
+
+ ppaace-addr_bitfields |= PAACE_V_VALID;
+ mb();
+
+ return 0;
+}
+
+/** Clears validation bit of PACCE
+ *
+ * @parm[in] liodn PAACT index for desired PAACE
+ *
+ * @return Returns 0 upon success else error code 0 returned
This is not proper kerneldoc format.
[Sethi Varun-B16395] What format must be used? Can you point me to a relevant
file.
+ */
+int pamu_disable_liodn(int liodn)
+{
+ paace_t *ppaace;
+
+ ppaace = pamu_get_ppaace(liodn);
+ if (!ppaace)
+ return -ENOENT;
error message?
[Sethi Varun-B16395] Error message at the point of invocation.
+
+ set_bf(ppaace-addr_bitfields, PAACE_AF_V, PAACE_V_INVALID);
+ mb();
+
+ return 0;
+}
+
+
+static unsigned int map_addrspace_size_to_wse(phys_addr_t
+addrspace_size) {
+ BUG_ON((addrspace_size (addrspace_size - 1)));
+
+ /* window size is 2^(WSE+1) bytes */
+ return __ffs(addrspace_size PAMU_PAGE_SHIFT) +
+PAMU_PAGE_SHIFT - 1; }
+
+static unsigned int map_subwindow_cnt_to_wce(u32 subwindow_cnt) {
+ /* window count is 2^(WCE+1) bytes */
+ return __ffs(subwindow_cnt) - 1; }
+
+static void pamu_setup_default_xfer_to_host_ppaace(paace_t *ppaace) {
+ set_bf(ppaace-addr_bitfields, PAACE_AF_PT, PAACE_PT_PRIMARY);
+
+ set_bf(ppaace-domain_attr.to_host.coherency_required,
PAACE_DA_HOST_CR,
+ PAACE_M_COHERENCE_REQ); }
+
+static void pamu_setup_default_xfer_to_host_spaace(paace_t *spaace) {
+ set_bf(spaace-addr_bitfields, PAACE_AF_PT,
PAACE_PT_SECONDARY);
+ set_bf(spaace-domain_attr.to_host.coherency_required,
PAACE_DA_HOST_CR,
+ PAACE_M_COHERENCE_REQ); }
+
+static paace_t *pamu_get_spaace(u32 fspi_index, u32 wnum) {
+ return spaact[fspi_index + wnum];
bounds checking?
[Sethi Varun-B16395] Ok.
+}
+
+static unsigned long pamu_get_fspi_and_allocate(u32 subwin_cnt) {
subwin_cnt should probably be an unsigned int.
[Sethi Varun-B16395] Why?
This function needs to be documented. What value is being returned?
+ unsigned long spaace_addr
RE: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, October 23, 2012 5:23 AM
To: Tabi Timur-B04825
Cc: Sethi Varun-B16395; joerg.roe...@amd.com; iommu@lists.linux-
foundation.org; linuxppc-...@lists.ozlabs.org; linux-
ker...@vger.kernel.org
Subject: Re: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU
API implementation.
On 10/22/2012 04:18:07 PM, Tabi Timur-B04825 wrote:
On Wed, Oct 17, 2012 at 12:32 PM, Varun Sethi
varun.se...@freescale.com wrote:
+}
+
+static unsigned long pamu_get_fspi_and_allocate(u32 subwin_cnt) {
subwin_cnt should probably be an unsigned int.
This function needs to be documented. What value is being returned?
spaact offset (yes, this needs to be documented)
[Sethi Varun-B16395] Ok.
+/* This bitmap advertises the page sizes supported by PAMU hardware
+ * to the IOMMU API.
+ */
+#define FSL_PAMU_PGSIZES (~0xFFFUL)
There should be a better way to define this. ~(PAMU_PAGE_SIZE-1)
maybe?
Is it even true? We don't support IOMMU pages larger than the SoC can
address.
The (~0xFFFUL) version also discards some valid IOMMU page sizes on 32-
bit kernels. One use case for windows larger than the CPU virtual
address space is creating one big identity-map window to effectively
disable translation. If we're to support that, the size of pgsize_bitmap
will need to change as well.
[Sethi Varun-B16395] Correct, this needs to be fixed. I will try to address this
In a separate patch (would require changes to iommu_map).
+static int map_liodn(int liodn, struct fsl_dma_domain *dma_domain)
+{
+ u32 subwin_cnt = dma_domain-subwin_cnt;
+ unsigned long rpn;
+ int ret = 0, i;
+
+ if (subwin_cnt) {
+ struct dma_subwindow *sub_win_ptr =
+ dma_domain-sub_win_arr[0];
+ for (i = 0; i subwin_cnt; i++) {
+ if (sub_win_ptr[i].valid) {
+ rpn = sub_win_ptr[i].paddr
+PAMU_PAGE_SHIFT,
+ spin_lock(iommu_lock);
+ ret = pamu_config_spaace(liodn,
subwin_cnt, i,
+
sub_win_ptr[i].size,
+-1,
+rpn,
+
dma_domain-snoop_id,
+
dma_domain-stash_id,
+(i 0) ?
1 : 0,
+
sub_win_ptr[i].prot);
+ spin_unlock(iommu_lock);
+ if (ret) {
+ pr_err(PAMU SPAACE
configuration failed for liodn %d\n,
+liodn);
+ return ret;
+ }
+ }
+ }
Break up that nesting with some subfunctions.
+ while (!list_empty(dma_domain-devices)) {
+ info = list_entry(dma_domain-devices.next,
+ struct device_domain_info, link);
+ remove_domain_ref(info, dma_domain-subwin_cnt);
+ }
I wonder if you should use list_for_each_safe() instead.
The above is simpler if you're destroying the entire list.
+}
+
+static int configure_domain_dma_state(struct fsl_dma_domain
*dma_domain, int enable)
bool enable
Finally, please CC: me on all IOMMU and PAMU patches you post
upstream.
Me too.
[Sethi Varun-B16395] Sure.
-Varun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 0/3 v2] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Varun Sethi varun.se...@freescale.com This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Addition of domain attributes required by the PAMU driver IOMMU API. 3. PAMU driver and IOMMU API implementation. This patch set is based on the next branch of the iommu git tree maintained by Joerg. Varun Sethi (3): Store iommu domain information pointer in archdata. Add iommu domain attributes required by fsl PAMU driver. FSL PAMU driver and IOMMU API implementation. arch/powerpc/include/asm/device.h |4 + drivers/iommu/Kconfig |7 + drivers/iommu/Makefile|1 + drivers/iommu/fsl_pamu.c | 1033 + drivers/iommu/fsl_pamu.h | 377 ++ drivers/iommu/fsl_pamu_domain.c | 990 +++ drivers/iommu/fsl_pamu_domain.h | 94 drivers/iommu/fsl_pamu_proto.h| 49 ++ include/linux/iommu.h | 30 ++ 9 files changed, 2585 insertions(+), 0 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h create mode 100644 drivers/iommu/fsl_pamu_proto.h -- 1.7.4.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/3 v2] iommu/fsl: Store iommu domain information pointer in archdata.
From: Varun Sethi varun.se...@freescale.com
Add a new field in the device (powerpc) archdata structure for storing iommu
domain
information pointer. This pointer is stored when the device is attached to a
particular
domain.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/include/asm/device.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..6dc79fe 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,10 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+ /* IOMMU domain information pointer. This would be set
+* when this device is attached to an iommu_domain.
+*/
+ void*iommu_domain;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/3 v2] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
From: Varun Sethi varun.se...@freescale.com
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
include/linux/iommu.h | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f3b99e1..62e22f0 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,33 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be mapped*/
dma_addr_t aperture_end; /* Last address that can be mapped */
bool force_aperture; /* DMA only allowed in mappable range? */
+
+ /* The subwindows field indicates number of DMA subwindows supported
+* by the geometry. Following is the interpretation of
+* values for this field:
+* 0 : This implies that the supported geometry size is 1 MB
+ * with each subwindow size being 4KB. Thus number of subwindows
+* being = 1MB/4KB = 256.
+* 1 : Only one DMA window i.e. no subwindows.
+* value other than 0 or 1 would indicate actual number of subwindows.
+*/
+ u32 subwindows;
+};
+
+/* cache stash targets */
+#define L1_CACHE 1
+#define L2_CACHE 2
+#define L3_CACHE 3
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
};
struct iommu_domain {
@@ -60,6 +87,14 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ /* Set the IOMMU hardware stashing
+* parameters.
+*/
+ DOMAIN_ATTR_STASH,
+ /* Explicity enable/disable DMA for a
+ * particular memory window.
+ */
+ DOMAIN_ATTR_ENABLE,
};
#ifdef CONFIG_IOMMU_API
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/3 v2] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Thursday, October 04, 2012 6:47 PM
To: Sethi Varun-B16395
Cc: joerg.roe...@amd.com; iommu@lists.linux-foundation.org; linuxppc-
d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; Sethi Varun-B16395
Subject: Re: [PATCH 2/3 v2] iommu/fsl: Add iommu domain attributes
required by fsl PAMU driver.
On Oct 4, 2012, at 6:56 AM, b16...@freescale.com b16...@freescale.com
wrote:
From: Varun Sethi varun.se...@freescale.com
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
include/linux/iommu.h | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
f3b99e1..62e22f0 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,33 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be mapped
*/
dma_addr_t aperture_end; /* Last address that can be mapped
*/
bool force_aperture; /* DMA only allowed in mappable range?
*/
+
+ /* The subwindows field indicates number of DMA subwindows
supported
+* by the geometry. Following is the interpretation of
+* values for this field:
+* 0 : This implies that the supported geometry size is 1 MB
+ * with each subwindow size being 4KB. Thus number of
subwindows
+* being = 1MB/4KB = 256.
+* 1 : Only one DMA window i.e. no subwindows.
+* value other than 0 or 1 would indicate actual number of
subwindows.
+*/
+ u32 subwindows;
+};
+
+/* cache stash targets */
+#define L1_CACHE 1
+#define L2_CACHE 2
+#define L3_CACHE 3
These names are way to generic for being exposed to user space
Will fix naming to IOMMU_ATTR_CACHE_L1 etc.
-Varun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, September 20, 2012 5:42 AM
To: Kumar Gala
Cc: Sethi Varun-B16395; joerg.roe...@amd.com; iommu@lists.linux-
foundation.org; linuxppc-...@lists.ozlabs.org; linux-
ker...@vger.kernel.org; Sethi Varun-B16395
Subject: Re: [RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes
required by fsl PAMU driver.
On 09/19/2012 08:52:27 AM, Kumar Gala wrote:
On Sep 19, 2012, at 8:17 AM, b16...@freescale.com
b16...@freescale.com wrote:
From: Varun Sethi varun.se...@freescale.com
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
include/linux/iommu.h | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
7e83370..eaa40c6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,28 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be
mapped*/
dma_addr_t aperture_end; /* Last address that can be
mapped */
bool force_aperture; /* DMA only allowed in mappable
range? */
+
+ /* The subwindows field indicates number of DMA subwindows
supported
+ * by the geometry. Following is the interpretation of
+ * values for this field:
+ * 0 : This implies that the supported geometry size is 1 MB
+ * with each subwindow size being 4KB. Thus number of
subwindows
+ * being = 1MB/4KB = 256.
+ * 1 : Only one DMA window i.e. no subwindows.
+ * value other than 0 or 1 would indicate actual number of
subwindows.
+ */
+ u32 subwindows;
+};
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
seems like this should be enum instead of u32 for cache
With enum being something like:
enum iommu_attr_stash_cache {
IOMMU_ATTR_CACHE_L1,
IOMMU_ATTR_CACHE_L2,
IOMMU_ATTR_CACHE_L3,
};
Don't we want these structs to be usable via some VFIO ioctl? In that
case they need to use fixed size types.
Yes, this would be usable via vfio ioctl. But, then the caller should be
aware of supported stash targets. May be I should add an interface for the
caller,
to query supported stash targets.
-Varun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC][PATCH 0/3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Varun Sethi varun.se...@freescale.com This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Addition of domain attributes required by the PAMU driver IOMMU API. 3. PAMU driver and IOMMU API implementation. Varun Sethi (3): Store iommu domain information pointer in archdata. Add iommu domain attributes required by fsl PAMU driver. FSL PAMU driver and IOMMU API implementation. arch/powerpc/include/asm/device.h |4 + drivers/iommu/Kconfig |7 + drivers/iommu/Makefile|1 + drivers/iommu/fsl_pamu.c | 1033 + drivers/iommu/fsl_pamu.h | 377 ++ drivers/iommu/fsl_pamu_domain.c | 990 +++ drivers/iommu/fsl_pamu_domain.h | 94 drivers/iommu/fsl_pamu_proto.h| 49 ++ include/linux/iommu.h | 30 ++ 9 files changed, 2585 insertions(+), 0 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h create mode 100644 drivers/iommu/fsl_pamu_proto.h -- 1.7.4.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC][PATCH 1/3] iommu/fsl: Store iommu domain information pointer in archdata.
From: Varun Sethi varun.se...@freescale.com
Add a new field in the device (powerpc) archdata structure for storing iommu
domain
information pointer. This pointer is stored when the device is attached to a
particular
domain.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/include/asm/device.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..6dc79fe 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,10 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+ /* IOMMU domain information pointer. This would be set
+* when this device is attached to an iommu_domain.
+*/
+ void*iommu_domain;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
--
1.7.4.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/7] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel
Sent: Wednesday, July 11, 2012 4:19 PM
To: iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org
Subject: [PATCH 2/7] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute
Implement the attribute itself and add the code for the AMD IOMMU driver.
Signed-off-by: Joerg Roedel joerg.roe...@amd.com
---
drivers/iommu/amd_iommu.c |4
drivers/iommu/iommu.c | 19 ---
include/linux/iommu.h |8
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index
a2e418c..259a6be 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3069,6 +3069,10 @@ static int amd_iommu_domain_init(struct
iommu_domain *dom)
dom-priv = domain;
+ dom-geometry.aperture_start = 0;
+ dom-geometry.aperture_end = ~0ULL;
+ dom-geometry.force_aperture = true;
+
return 0;
out_free:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index
c39972d..ed5e0a5 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -348,10 +348,23 @@ EXPORT_SYMBOL_GPL(iommu_device_group);
int iommu_domain_get_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
{
- if (!domain-ops-domain_get_attr)
- return -EINVAL;
+ struct iommu_domain_geometry *geometry;
+ int ret = 0;
+
+ switch (attr) {
+ case DOMAIN_ATTR_GEOMETRY:
+ geometry = data;
+ *geometry = domain-geometry;
+
+ break;
+ default:
+ if (!domain-ops-domain_get_attr)
+ return -EINVAL;
- return domain-ops-domain_get_attr(domain, attr, data);
+ ret = domain-ops-domain_get_attr(domain, attr, data);
+ }
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_domain_get_attr);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index
0eef096..f7df4aa 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -37,11 +37,18 @@ struct iommu_domain; typedef int
(*iommu_fault_handler_t)(struct iommu_domain *,
struct device *, unsigned long, int, void *);
+struct iommu_domain_geometry {
+ dma_addr_t aperture_start; /* First address that can be mapped
*/
+ dma_addr_t aperture_end; /* Last address that can be mapped
*/
+ bool force_aperture; /* DMA only allowed in mappable range?
*/
+};
+
struct iommu_domain {
struct iommu_ops *ops;
void *priv;
iommu_fault_handler_t handler;
void *handler_token;
+ struct iommu_domain_geometry geometry;
};
Hi Joerg,
I am currently working on upstreaming the Freescale IOMMU driver. As discussed
(with Scott Wood)
a while back, this representation of the GEOMETRY attribute doesn't go well
with our IOMMU
implementation. Our representation of the geometry would be more complex and is
certainly modifiable.
Our IOMMU allows for creating custom DMA mappings by defining a set of DMA sub
windows within
a given window. We need a mechanism for specifying the number of DMA subwindows
as a part of the
domain geometry. My suggestion would be to make the GEOMETRY attribute
implementation dependent
Regards
Varun
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/7] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute
-Original Message- From: Joerg Roedel [mailto:joerg.roe...@amd.com] Sent: Wednesday, July 11, 2012 5:47 PM To: Sethi Varun-B16395 Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH 2/7] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute Hi Sethi, On Wed, Jul 11, 2012 at 11:47:39AM +, Sethi Varun-B16395 wrote: I am currently working on upstreaming the Freescale IOMMU driver. As discussed (with Scott Wood) a while back, this representation of the GEOMETRY attribute doesn't go well with our IOMMU implementation. Our representation of the geometry would be more complex and is certainly modifiable. Our IOMMU allows for creating custom DMA mappings by defining a set of DMA sub windows within a given window. We need a mechanism for specifying the number of DMA subwindows as a part of the domain geometry. My suggestion would be to make the GEOMETRY attribute implementation dependent Yeah, we had some discussions in the past and I came to the conclusion that its best to wait for your code and decide then if and how to change the interface to better suit your needs. The interface is not exposed to userspace so we can easily change it. People are waiting for this feature and I don't want to delay it further unless it is absolutly necessary. The API call for setting domain attributes is an essential part of our implementation and GEOMETRY is a critical attribute for us. I am currently working on our driver and hopefully should be able to submit it in the next two weeks. In my case I was planning on letting the geometry attribute be implementation dependent. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
