RE: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
> > On Tegra, the following use cases need specific IOVA mapping. > > 1. Few MMIO blocks need IOVA=PA mapping setup. > > In that case, why would we enable the IOMMU for that one device; IOMMU > disabled means VA==PA, right? Perhaps isolation of the device so it can only > access certain PA ranges for security? The device(H/W controller) need to access few special memory blocks(IOVA==PA) and DRAM as well. If IOMMU is disabled, then it has to handle memory fragmentation, which defeats the purpose of IOMMU support. There is also a case where frame buffer memory is passed from BootLoader to Kernel and display H/W continues to access it with IOMMU enabled. To support this, the one to one mapping has to be setup before enabling IOMMU. -KR ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
On 09/19/2012 07:44 PM, Krishna Reddy wrote: >> When a device driver would only use the IOMMU-API and needs small DMA- >> able areas it has to re-implement something like the DMA-API (basically an >> address allocator) for that. So I don't see a reason why both can't be used >> in a >> device driver. > > On Tegra, the following use cases need specific IOVA mapping. > 1. Few MMIO blocks need IOVA=PA mapping setup. In that case, why would we enable the IOMMU for that one device; IOMMU disabled means VA==PA, right? Perhaps isolation of the device so it can only access certain PA ranges for security? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
> When a device driver would only use the IOMMU-API and needs small DMA-
> able areas it has to re-implement something like the DMA-API (basically an
> address allocator) for that. So I don't see a reason why both can't be used
> in a
> device driver.
On Tegra, the following use cases need specific IOVA mapping.
1. Few MMIO blocks need IOVA=PA mapping setup.
2. CPU side loads the firmware into physical memory, which has to be
mapped to a specific IOVA address, as firmware is statically linked based
on specific IOVA address.
DMA api's allow specifying only one address space per platform device.
For #1, DMA API can't be used as it doesn't allow mapping specific IOVA to PA.
IOMMU API can be used for mapping specific IOVA to PA. But, in order to use
IOMMU API, the driver has to dereference the dev pointer, get domain ptr,
take lock, and allocate memory from dma_iommu_mapping. This breaks
the abstraction for struct device. Each device driver that need IOVA=PA has to
do this, which is redundant.
For #2, physical memory allocations alone can be done through DMA as it also
allocates IOVA space Implicitly. Even after allocating physical memory through
DMA API's, it would have same problem as #1 for IOVA to PA mapping.
If a fake device is expected to be created for specific IOVA allocation, then it
may lead to creating multiple fake devices per specific IOVA and per
ASID(unique IOVA address space). As domain init would be done based on
device name, the fake device should have the same name as of original platform
device.
If DMA API allows allocating specific IOVA address and mapping IOVA to specific
PA,
device driver don't need to know any details of struct device and specifying
one mapping per device is enough and no need for fake devices.
Comments are much appreciated.
-KR
> -Original Message-
> From: Joerg Roedel [mailto:joerg.roe...@amd.com]
> Sent: Wednesday, September 19, 2012 5:50 AM
> To: Arnd Bergmann
> Cc: Hiroshi Doyu; m.szyprow...@samsung.com; li...@arm.linux.org.uk;
> minc...@kernel.org; chunsang.je...@linaro.org; linux-
> ker...@vger.kernel.org; subas...@gmail.com; linaro-mm-...@lists.linaro.org;
> linux...@kvack.org; iommu@lists.linux-foundation.org; Krishna Reddy; linux-
> te...@vger.kernel.org; kyungmin.p...@samsung.com;
> pullip@samsung.com; linux-arm-ker...@lists.infradead.org
> Subject: Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA
> more precisely
>
> On Wed, Sep 19, 2012 at 07:59:45AM +, Arnd Bergmann wrote:
> > On Wednesday 19 September 2012, Hiroshi Doyu wrote:
> > > I guess that it would work. Originally I thought that using DMA-API
> > > and IOMMU-API together in driver might be kind of layering violation
> > > since IOMMU-API itself is used in DMA-API. Only DMA-API used in
> > > driver might be cleaner. Considering that DMA API traditionally
> > > handling anonymous {bus,iova} address only, introducing the concept
> > > of specific address in DMA API may not be so encouraged, though.
> > >
> > > It would be nice to listen how other SoCs have solved similar needs.
> >
> > In general, I would recommend using only the IOMMU API when you have a
> > device driver that needs to control the bus virtual address space and
> > that manages a device that resides in its own IOMMU context. I would
> > recommend using only the dma-mapping API when you have a device that
> > lives in a shared bus virtual address space with other devices, and
> > then never ask for a specific bus virtual address.
> >
> > Can you explain what devices you see that don't fit in one of those
> > two categories?
>
> Well, I don't think that a driver should limit to one of these 2 APIs. A
> driver can
> very well use the IOMMU-API during initialization (for example to map the
> firmware to an address the device expects it to be) and use the DMA-API later
> during normal operation to exchange data with the device.
>
> When a device driver would only use the IOMMU-API and needs small DMA-
> able areas it has to re-implement something like the DMA-API (basically an
> address allocator) for that. So I don't see a reason why both can't be used
> in a
> device driver.
>
> Regards,
>
> Joerg
>
> --
> AMD Operating System Research Center
>
> Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General
> Managers: Alberto Bozzo
> Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr.
> 43632
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 1/3] iommu/fsl: Store iommu domain information pointer in archdata.
On Sep 19, 2012, at 8:17 AM,
wrote:
> From: Varun Sethi
>
> 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
> ---
> arch/powerpc/include/asm/device.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
Not too familiar, but what does the IBM Server IOMMU do for iommu_domain?
>
> 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
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
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.
On Sep 19, 2012, at 8:17 AM,
wrote:
> From: Varun Sethi
>
> 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
> ---
> 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,
};
> };
>
> struct iommu_domain {
> @@ -60,6 +82,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
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 0/3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
On Sep 19, 2012, at 8:17 AM, wrote: > From: Varun Sethi > > 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 I assume that another patch series will add device tree binding spec and update device trees for SoCs with PAMU? - k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC][PATCH 2/3] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
From: Varun Sethi
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
---
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 */
};
struct iommu_domain {
@@ -60,6 +82,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
[RFC][PATCH 1/3] iommu/fsl: Store iommu domain information pointer in archdata.
From: Varun Sethi
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
---
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
[RFC][PATCH 0/3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Varun Sethi 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
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
On Wed, Sep 19, 2012 at 07:59:45AM +, Arnd Bergmann wrote:
> On Wednesday 19 September 2012, Hiroshi Doyu wrote:
> > I guess that it would work. Originally I thought that using DMA-API
> > and IOMMU-API together in driver might be kind of layering violation
> > since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
> > might be cleaner. Considering that DMA API traditionally handling
> > anonymous {bus,iova} address only, introducing the concept of
> > specific address in DMA API may not be so encouraged, though.
> >
> > It would be nice to listen how other SoCs have solved similar needs.
>
> In general, I would recommend using only the IOMMU API when you have a device
> driver that needs to control the bus virtual address space and that manages
> a device that resides in its own IOMMU context. I would recommend using
> only the dma-mapping API when you have a device that lives in a shared
> bus virtual address space with other devices, and then never ask for
> a specific bus virtual address.
>
> Can you explain what devices you see that don't fit in one of those two
> categories?
Well, I don't think that a driver should limit to one of these 2 APIs. A
driver can very well use the IOMMU-API during initialization (for
example to map the firmware to an address the device expects it to be)
and use the DMA-API later during normal operation to exchange data with
the device.
When a device driver would only use the IOMMU-API and needs small
DMA-able areas it has to re-implement something like the DMA-API
(basically an address allocator) for that. So I don't see a reason why
both can't be used in a device driver.
Regards,
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
Hi Arnd,
On Wed, 19 Sep 2012 09:59:45 +0200
Arnd Bergmann wrote:
> On Wednesday 19 September 2012, Hiroshi Doyu wrote:
> > I guess that it would work. Originally I thought that using DMA-API
> > and IOMMU-API together in driver might be kind of layering violation
> > since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
> > might be cleaner. Considering that DMA API traditionally handling
> > anonymous {bus,iova} address only, introducing the concept of
> > specific address in DMA API may not be so encouraged, though.
> >
> > It would be nice to listen how other SoCs have solved similar needs.
>
> In general, I would recommend using only the IOMMU API when you have a device
> driver that needs to control the bus virtual address space and that manages
> a device that resides in its own IOMMU context. I would recommend using
> only the dma-mapping API when you have a device that lives in a shared
> bus virtual address space with other devices, and then never ask for
> a specific bus virtual address.
>
> Can you explain what devices you see that don't fit in one of those two
> categories?
I think that the above fis, but I'll continue to explain our case a little
bit more below:
In Tegra, there's a few dozen of IOMMU'able devices. Each of them can
be configured to enable/disable IOMMU. Also some IOMMU Address Space
IDs(ASID) can be assigned to each device respectively. Some of devices
are just traditional ones to use traditional dma-mapping API only,
like normal SD/MMC. Some of devices require some specific IOVA address
for reset vector and MMIO. For example, Tegra has another ARM(ARM7) as
such. For traditional devices, dma mapping API is so nice that driver
doesn't have to be aware of IOMMU. The same dma mapping API works
with/without IOMMU.
If both devices are attached to the same mapping, IOMMU-API and
dma-mapping API would be used together from different
devices. Technically this can be avoided to assign different maps to
each device, though.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely
On Wednesday 19 September 2012, Hiroshi Doyu wrote:
> I guess that it would work. Originally I thought that using DMA-API
> and IOMMU-API together in driver might be kind of layering violation
> since IOMMU-API itself is used in DMA-API. Only DMA-API used in driver
> might be cleaner. Considering that DMA API traditionally handling
> anonymous {bus,iova} address only, introducing the concept of
> specific address in DMA API may not be so encouraged, though.
>
> It would be nice to listen how other SoCs have solved similar needs.
In general, I would recommend using only the IOMMU API when you have a device
driver that needs to control the bus virtual address space and that manages
a device that resides in its own IOMMU context. I would recommend using
only the dma-mapping API when you have a device that lives in a shared
bus virtual address space with other devices, and then never ask for
a specific bus virtual address.
Can you explain what devices you see that don't fit in one of those two
categories?
Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
