ds/mh/dma-priv
> The following patch to the ARM SMMU driver:
>
> commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
> Author: Robin Murphy
> Date: Tue Jan 26 18:06:34 2016 +
>
> iommu/arm-smmu: Treat all device transactions as unprivileged
On 15/11/16 13:09, Eric Auger wrote:
> IOMMU_RESV_NOMAP is used to tag reserved IOVAs that are not
> supposed to be IOMMU mapped. IOMMU_RESV_MSI tags IOVAs
> corresponding to MSIs that need to be IOMMU mapped.
>
> IOMMU_RESV_MASK allows to check if the IOVA is reserved.
>
> Signed-off-by: Eric Au
long to another address space or because
> they are not translated by the IOMMU and need special handling)
>
> So let's rename the struct and also the callbacks.
Acked-by: Robin Murphy
> Signed-off-by: Eric Auger
> ---
> drivers/iommu/amd_iommu.c | 20 ++--
On 15/11/16 13:09, Eric Auger wrote:
> Introduce a new helper serving the purpose to allocate a reserved
> region. This will be used in iommu driver implementing reserved
> region callbacks.
>
> Signed-off-by: Eric Auger
> ---
> drivers/iommu/iommu.c | 16
> include/linux/iommu
On 15/11/16 13:09, Eric Auger wrote:
> As we introduced IOMMU_RESV_NOMAP and IOMMU_RESV_MSI regions,
> let's prevent those new regions from being mapped.
>
> Signed-off-by: Eric Auger
> ---
> drivers/iommu/iommu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c
On 15/11/16 13:09, Eric Auger wrote:
> Introduce iommu_get_group_resv_regions whose role consists in
> enumerating all devices from the group and collecting their
> reserved regions. It checks duplicates.
>
> Signed-off-by: Eric Auger
>
> ---
>
> - we do not move list elements from device to gr
On 15/11/16 13:09, Eric Auger wrote:
> The get() populates the list with the PCI host bridge windows
> and the MSI IOVA range.
>
> At the moment an arbitray MSI IOVA window is set at 0x800
> of size 1MB. This will allow to report those info in iommu-group
> sysfs?
>
> Signed-off-by: Eric Auge
On 04/12/16 07:48, Sricharan wrote:
> Hi Robin,
>
>> Hi Sricharan,
>>
>> On 02/12/16 14:55, Sricharan R wrote:
>>> This series is a resend of the V5 that Mitch sent sometime back [2]
>>> All the patches are the same and i have just rebased. Not sure why this
>>> finally did not make it last time.
On 07/12/16 15:02, Auger Eric wrote:
> Hi Robin,
> On 06/12/2016 19:55, Robin Murphy wrote:
>> On 15/11/16 13:09, Eric Auger wrote:
>>> The get() populates the list with the PCI host bridge windows
>>> and the MSI IOVA range.
>>>
>>> At the moment
On 08/12/16 09:36, Auger Eric wrote:
> Hi,
>
> On 15/11/2016 14:09, Eric Auger wrote:
>> Following LPC discussions, we now report reserved regions through
>> iommu-group sysfs reserved_regions attribute file.
>
>
> While I am respinning this series into v4, here is a tentative summary
> of techn
On 08/12/16 13:36, Auger Eric wrote:
> Hi Robin,
>
> On 08/12/2016 14:14, Robin Murphy wrote:
>> On 08/12/16 09:36, Auger Eric wrote:
>>> Hi,
>>>
>>> On 15/11/2016 14:09, Eric Auger wrote:
>>>> Following LPC discussions, we now
On 08/12/16 17:01, Alex Williamson wrote:
> On Thu, 8 Dec 2016 13:14:04 +
> Robin Murphy wrote:
>> On 08/12/16 09:36, Auger Eric wrote:
>>> 3) RMRR reporting in the iommu group sysfs? Joerg: yes; Don: no
>>>My current series does not expose them in iommu gr
g to unprivileged, instead
> set it to default as incoming and let it be controlled by the pagetable
> settings.
>
> Acked-by: Will Deacon
> Signed-off-by: Sricharan R
Since everything else has already got my tags on it:
Reviewed-by: Robin Murphy
I'd say the whole series looks goo
t;
> Cc: linux-...@vger.kernel.org
> Reviewed-by: Robin Murphy
> Tested-by: Robin Murphy
> Acked-by: Will Deacon
> Signed-off-by: Mitchel Humpherys
> ---
> Documentation/DMA-attributes.txt | 10 ++
> include/linux/dma-mapping.h | 7 +++
> 2 file
gt;
> Reviewed-by: Robin Murphy
> Tested-by: Robin Murphy
> Acked-by: Will Deacon
> Signed-off-by: Mitchel Humpherys
> ---
> arch/arm64/mm/dma-mapping.c | 6 +++---
> drivers/iommu/dma-iommu.c | 10 --
> include/linux/dma-iommu.h | 3 ++-
> 3 files change
On 13/12/16 14:38, Sricharan wrote:
> Hi Robin,
>
>> -Original Message-
>> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>> On Behalf Of Robin Murphy
>> Sent: Tuesday, December 13, 2016 7:33 PM
>> To: Srichara
ing->domain, iova, phys, len, prot);
> if (ret < 0)
> @@ -1930,7 +1936,7 @@ static dma_addr_t arm_coherent_iommu_map_page(struct
> device *dev, struct page *p
> if (dma_addr == DMA_ERROR_CODE)
> return dma_addr;
>
> - prot = __dma_direction_to_prot(dir);
> + prot = __dma_info_to_prot(dir, attrs);
>
> ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len,
> prot);
> if (ret < 0)
> @@ -2036,7 +2042,7 @@ static dma_addr_t arm_iommu_map_resource(struct device
> *dev,
> if (dma_addr == DMA_ERROR_CODE)
> return dma_addr;
>
> - prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
> + prot = __dma_info_to_prot(dir, attrs) | IOMMU_MMIO;
>
> ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
> if (ret < 0)
>
Looks reasonable to me. Assuming it survives testing:
Acked-by: Robin Murphy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 16/12/16 02:36, Stuart Yoder wrote:
> For context, please see the thread:
> https://www.spinics.net/lists/arm-kernel/msg539066.html
>
> The existing iommu-map binding did not account for the situation where
> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
> of the IOMMU
. for MMU-500 configurations where the appended TBU
number gets in the way unnecessarily). Let's add a new property to allow
a single global mask value to better fit the latter situation.
CC: Stuart Yoder
Signed-off-by: Robin Murphy
---
Compile-tested only...
Documentation/devicetree/bin
On 16/12/16 14:21, Stuart Yoder wrote:
>
>
>> -Original Message-
>> From: Mark Rutland [mailto:mark.rutl...@arm.com]
>> Sent: Friday, December 16, 2016 5:39 AM
>> To: Stuart Yoder
>> Cc: robin.mur...@arm.com; will.dea...@arm.com; robh...@kernel.org; Bharat
>> Bhushan
>> ; Nipun Gupta ;
On 16/12/16 15:56, Stuart Yoder wrote:
> The existing iommu-map binding did not account for the situation where
> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
> of the IOMMU specifier being the SMR mask. The existing binding defines
> the mapping as:
>
egister/retrieve
> IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
> code in order to complete the interface rework.
Reviewed-by: Robin Murphy
Looking at before-and-after disassemblies, of_iommu.o is binary
identical, and exynos-iommu.o differs only in the use of dev-&
On 05/01/17 12:27, Lorenzo Pieralisi wrote:
> On Thu, Jan 05, 2017 at 02:04:37PM +0530, Sricharan wrote:
>> Hi Robin/Lorenzo,
>>
>>> Hi Robin,Lorenzo,
>>>
>>>> On Wed, Nov 30, 2016 at 04:42:27PM +, Robin Murphy wrote:
>>>>> On 30/1
On 05/01/17 14:47, Will Deacon wrote:
> On Thu, Jan 05, 2017 at 02:07:31PM +, Mark Rutland wrote:
>> On Thu, Jan 05, 2017 at 02:00:05PM +, Will Deacon wrote:
>>> On Thu, Jan 05, 2017 at 12:08:57PM +, Mark Rutland wrote:
On Thu, Jan 05, 2017 at 11:55:29AM +, Will Deacon wrote:
>
On 05/01/17 16:07, Will Deacon wrote:
> On Thu, Jan 05, 2017 at 03:32:50PM +0000, Robin Murphy wrote:
>> On 05/01/17 14:47, Will Deacon wrote:
>>> On Thu, Jan 05, 2017 at 02:07:31PM +, Mark Rutland wrote:
>>>> Ok. It would be good to elaborate on what "sta
On 06/01/17 11:46, Auger Eric wrote:
>
>
> On 06/01/2017 11:59, Joerg Roedel wrote:
>> On Thu, Jan 05, 2017 at 07:04:29PM +, Eric Auger wrote:
>>> struct iommu_dma_cookie {
>>> - struct iova_domain iovad;
>>> - struct list_headmsi_page_list;
>>> - spinlock_t m
Hi Marek,
On 09/01/17 12:03, Marek Szyprowski wrote:
> This patch prepares Exynos IOMMU driver for deferred probing
> support. Once it gets added, of_xlate() callback might be called
> more than once for the same SYSMMU controller and master device
> (for example it happens when masters device dri
On 09/01/17 13:45, Eric Auger wrote:
> From: Robin Murphy
>
> Whilst PCI devices may have 64-bit DMA masks, they still benefit from
> using 32-bit addresses wherever possible in order to avoid DAC (PCI) or
> longer address packets (PCIe), which may incur a performance overhead.
- we enable 16-bit VMID unconditionally where
supported, so I don't see any reason not to handle 16-bit ASIDs in the
same manner.
> + cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64)
> + reg2 |= TTBCR2_AS;
> }
> if (smmu->version &g
On 10/01/17 11:57, Aleksey Makarov wrote:
> Enable the Extended Stream ID feature when available.
>
> This patch on top of series "[PATCH v7 00/19] KVM PCIe/MSI passthrough
> on ARM/ARM64 and IOVA reserved regions" by Eric Auger allows
> to passthrough an external PCIe network card on a ThunderX s
On 13/01/17 10:43, Tomasz Nowicki wrote:
> On 12.01.2017 07:41, Tomasz Nowicki wrote:
>> On 11.01.2017 13:19, Robin Murphy wrote:
>>> On 11/01/17 11:51, Tomasz Nowicki wrote:
>>>> The goal of erratum #27704 workaround was to make sure that ASIDs and
>>>
On 13/01/17 11:07, Geert Uytterhoeven wrote:
> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
> This allows to allocate physically contiguous DMA buffers on arm64
> systems with an IOMMU.
Can anyone explain what this attribute is actually used for? I've never
quite figure
On 13/01/17 11:59, Geert Uytterhoeven wrote:
> Hi Robin,
>
> On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy wrote:
>> On 13/01/17 11:07, Geert Uytterhoeven wrote:
>>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
>>> This allows to a
h_device() on the default domain,
and refactor the error handling paths to cope with its failure and clean
up correctly in such cases.
Fixes: e39cb8a3aa98 ("iommu: Make sure a device is always attached to a domain")
Reported-by: Punit Agrawal
Signed-off-by: Robin Murphy
---
dri
a subset of the available 64-bit space.
Signed-off-by: Robin Murphy
---
Sending this as a v2 since both patches have been seen before, and #1 is
ever so slightly tweaked. #2 applies on top of Eric's MSI series, since
that seems ready to go now - there is a trivial merge conflict otherwise
a
first, only falling back to the full mask if that fails.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9aa432e8fbd3..8adff5f83b38
.com
>
> Signed-off-by: Aleksey Makarov
> ---
> v2:
> - remove unnecessary parentheses (Robin Murphy)
> - refactor testing SMR fields to after setting sCR0 as theirs width
> depends on sCR0_EXIDENABLE (Robin Murphy)
>
> v1 (rfc):
> https://lkml.kernel.org/r/201
On 19/01/17 15:05, Sricharan R wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver probe is called. This way, configur
On 19/01/17 16:50, Lorenzo Pieralisi wrote:
> On Thu, Jan 19, 2017 at 08:35:52PM +0530, Sricharan R wrote:
>> From: Robin Murphy
>>
>> Now that the appropriate ordering is enforced via profe-deferral of
>> masters in core code, rip it all out and bask in the simplicity.
On 19/01/17 18:19, Will Deacon wrote:
> The ARM SMMU drivers provide a DOMAIN_ATTR_NESTING domain attribute,
> which allows callers of the IOMMU API to request that the page table
> for a domain is installed at stage-2, if supported by the hardware.
>
> Since setting this attribute only makes sens
lly more abundant.
Reviewed-by: Robin Murphy
> Signed-off-by: Will Deacon
> ---
> drivers/iommu/arm-smmu.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index a328ffb75509..
On 19/01/17 18:19, Will Deacon wrote:
> In preparation for allowing the default domain type to be overridden,
> this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
> ARM SMMUv3 driver.
>
> An identity domain is created by placing the corresponding stream table
> entries into "bypass"
traight away. The DMA ops can't be expected to work
successfully on any old domain, so it's a reasonable sanity check
regardless.
Reviewed-by: Robin Murphy
> Signed-off-by: Will Deacon
> ---
> arch/arm64/mm/dma-mapping.c | 17 -
> 1 file changed, 12 inser
Hi Magnus,
On 23/01/17 12:12, Magnus Damm wrote:
> From: Magnus Damm
>
> Consider failure of iommu_get_domain_for_dev() as non-critical and
> get rid of the warning printout. This allows IOMMU properties to be
> included in the DTB even though the kernel is configured with
> CONFIG_IOMMU_API=n o
On 25/01/17 12:54, Yoshihiro Shimoda wrote:
> In the future, the init_iova_rcaches will be called in atomic.
That screams "doing the wrong thing". The sole point of the rcaches is
to reuse IOVAs, whereas the main point of this series seems to involve
not reusing IOVAs. The fact that we have to aff
On 25/01/17 12:53, Yoshihiro Shimoda wrote:
> From: Magnus Damm
>
> To track mapped iova for a workaround code in the future.
>
> Signed-off-by: Magnus Damm
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/iommu/dma-iommu.c | 29 +++--
> include/linux/iommu.h |
On 25/01/17 12:54, Yoshihiro Shimoda wrote:
> From: Magnus Damm
>
> To add a workaround code for ipmmu-vmsa driver, this patch adds
> a new geometry "force_reset_when_empty" not to reuse iova space.
The domain geometry is absolutely not the appropriate place for that. If
anything, it could possi
On 25/01/17 16:23, Geert Uytterhoeven wrote:
> Hi Robin,
Hi Geert,
> On Mon, May 9, 2016 at 11:37 AM, Robin Murphy wrote:
>> On 08/05/16 11:59, Niklas Söderlund wrote:
>>> While using CONFIG_DMA_API_DEBUG i came across this warning which I
>>> think
Hi Tomasz,
On 25/01/17 17:17, Tomasz Nowicki wrote:
> Hi Sricharan,
>
> On 23.01.2017 17:18, Sricharan R wrote:
>> From: Robin Murphy
>>
>> In preparation for some upcoming cleverness, rework the control flow in
>> of_iommu_configure() to minimise duplication
SYS-DMAC) rightfully configures a 40-bit DMA
> mask, it will still be handed out a 40-bit IOVA, outside the 32-bit IOVA
> space, leading to out-of-bounds accesses of the PGD when mapping the
> IOVA.
>
> Force a 32-bit IOMMU Domain Geometry to fix this.
Reviewed-by: Robin Murphy
On 26/01/17 17:15, Joerg Roedel wrote:
> On Thu, Jan 19, 2017 at 06:19:15PM +, Will Deacon wrote:
>> Rather than modify each IOMMU driver to provide different semantics for
>> DMA domains, instead we introduce a command line parameter that can be
>> used to change the type of the default domain
This is a fairly subtle thing - let's make sure it's described as
clearly as possible to avoid potential misunderstandings.
Signed-off-by: Robin Murphy
---
Having another look through the IOMMU_PRIV series, I wasn't convinced
that the original comment was really all that helpful
Hi Magnus,
On 27/01/17 06:24, Magnus Damm wrote:
> From: Magnus Damm
>
> Introduce the flag "no_size_align" to allow disabling size-alignment
> on a per-domain basis. This follows the suggestion by the comment
> in the code, however a per-device control may be preferred?
>
> Needed to make virt
er.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v2:
> - Provide standalone iommu_dma_{alloc,free}_contiguous() functions, as
> requested by Robin Murphy,
> - Simplify operations by getting rid of the page array/scatterlist
> dance, as the buffer is contiguous,
>
On 27/01/17 18:00, Sricharan wrote:
> Hi Robin,
>
> [..]
>
+const struct iommu_ops *of_iommu_configure(struct device *dev,
+ struct device_node *master_np)
+{
+const struct iommu_ops *ops;
+
+if (!master_np)
+return NULL;
>>
On 30/01/17 07:20, Yoshihiro Shimoda wrote:
> Hi Robin, Magnus,
>
>> -Original Message-----
>> From: Robin Murphy
>> Sent: Saturday, January 28, 2017 2:38 AM
>>
>> Hi Magnus,
>>
>> On 27/01/17 06:24, Magnus Damm wrote:
>>> From: Magnus
On 29/01/17 17:53, Sinan Kaya wrote:
> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>> [+hanjun, tomasz, sinan]
>>
>> It is quite a key patchset, I would be glad if they can test on their
>> respective platforms with IORT.
>>
>
> Tested on top of 4.10-rc5.
>
> 1.Platform Hidma device passed
On 30/01/17 07:00, Sricharan wrote:
> Hi Robin,
>
>>> [..]
>>>
>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>> + struct device_node *master_np)
>> +{
>> +const struct iommu_ops *ops;
>> +
>> +if (!master_np)
>> +
othing but duplicate the current default behaviour;
we already constrain IOVA allocations to the iommu_domain aperture where
necessary, so let's leave DMA mask business to architecture-specific
code where it belongs.
Signed-off-by: Robin Murphy
---
Techincally an IOMMU patch, but could possib
-
> v3:
> - Add Acked-by,
> - Update comment to "one of _4_ things",
> - Call dma_alloc_from_contiguous() and iommu_dma_map_page() directly,
> as suggested by Robin Murphy,
>
> v2:
> - New, handle dispatching in the arc
sn't uninitialised, but still directly
equivalent to the old one, I don't see an issue with moving the
assignemnt there, plus it does avoid a redundant reassignment the first
time through.
Reviewed-by: Robin Murphy
> return 0;
> }
> EXPORT_SYMBOL_GPL(iommu_fwspe
On 03/02/17 16:15, Sricharan wrote:
> Hi Lorenzo, Robin,
>
>> -Original Message-
>> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>> On Behalf Of Sricharan R
>> Sent: Friday, February 03, 2017 9:19 PM
>> To: robin.mur...@arm.com; will.dea...@arm.com; j...@8b
On 08/02/17 12:30, Sricharan wrote:
> Hi Mark,
>
>> On Wed, Feb 08, 2017 at 04:23:17PM +0530, Sricharan wrote:
On Thu, Feb 02, 2017 at 10:40:18PM +0530, Sricharan R wrote:
> +- clock-names:Should be a pair of "smmu_iface_clk" and "smmu_bus_clk"
> + required for sm
On 08/02/17 13:52, Mark Rutland wrote:
> On Wed, Feb 08, 2017 at 07:15:37PM +0530, Sricharan wrote:
>>> Clocks are not architectural, so it only makes sense to associate them
>>> with an implementation-specific compatible string. There's also no
>>
>> ok, it for this the QCOM specific implementatio
Hi Joerg,
I'm really liking this series! Superficially it doesn't seem to break
anything on my Juno, but I'll give it a more thorough workout soon.
Just a few comments from skimming through...
On 09/02/17 11:32, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Rename the function to iommu_ops_from
On 09/02/17 11:32, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Allow to store a fwnode in 'struct iommu_device';
>
> Signed-off-by: Joerg Roedel
> ---
> include/linux/iommu.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
On 09/02/17 11:32, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Also add the smmu devices to sysfs.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/arm-smmu-v3.c | 22 +-
> drivers/iommu/arm-smmu.c| 30 ++
> 2 files changed, 51 insertio
On 09/02/17 11:32, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Register the MSM IOMMUs to the iommu core and add sysfs
> entries for that driver.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/msm_iommu.c | 73
> +++
> drivers/iommu/msm_iomm
On 10/02/17 15:22, Joerg Roedel wrote:
> Hi Robin,
>
> On Fri, Feb 10, 2017 at 02:16:54PM +0000, Robin Murphy wrote:
>>> +static inline void iommu_device_set_fwnode(struct iommu_device *iommu,
>>> + struct fwnode_handle *fwnode)
&
On 10/02/17 16:11, Joerg Roedel wrote:
> On Fri, Feb 10, 2017 at 04:03:07PM +0000, Robin Murphy wrote:
>> Yeah, on reflection explicit initialisation is certainly easier to read
>> than a bunch of arguments handled implicitly by register(), but then
>> from that angle, even m
On 10/02/17 15:25, Joerg Roedel wrote:
> On Fri, Feb 10, 2017 at 02:20:34PM +0000, Robin Murphy wrote:
>>> @@ -1795,8 +1798,10 @@ static int arm_smmu_add_device(struct device *dev)
>>> }
>>>
>>> group = iommu_group_get_for_dev(dev);
>>> -
On 10/02/17 15:33, Joerg Roedel wrote:
> On Fri, Feb 10, 2017 at 02:35:39PM +0000, Robin Murphy wrote:
>> On 09/02/17 11:32, Joerg Roedel wrote:
>>> + ret = iommu_device_sysfs_add(&iommu->iommu, iommu->dev, NULL,
>>> +&quo
On 14/02/17 01:54, Sinan Kaya wrote:
> On 2/13/2017 8:46 PM, Alex Williamson wrote:
>>> My first goal is to support virtual function passthrough for device's that
>>> are directly
>>> connected. This will be possible with the quirk I proposed and it will be
>>> the most
>>> secure solution. It ca
Hi Rob,
On 10/02/17 18:41, Rob Clark wrote:
> For devices with iommu(s) in secure mode, we cannot touch global
> registers, and we have to live with the context -> sid mapping that
> the secure world has set up for us.
>
> This enables, for example db410c (apq8016) devices to use the up-
> stream
always uses physically contiguous buffers (up to
> IO_TLB_SEGSIZE = 128 pages),
> - arm64's __dma_alloc_coherent() already calls
> dma_alloc_from_contiguous() when CMA is available.
I think this looks about as good as it ever could now :)
Reviewed-by: Robin Murphy
Thanks,
Robin
On 16/02/17 13:52, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Do a check for already installed leaf entry at the current level before
> performing any actions when trying to map.
>
> This check is already present in arm_v7s_init_pte(), i.e. before
> installing new leaf entry at
On 22/02/17 11:00, Joerg Roedel wrote:
> Hi Dan,
>
> thanks for the report! There are more bogus things going on here.
>
> On Wed, Feb 15, 2017 at 11:36:48AM +0300, Dan Carpenter wrote:
>> The patch 9648cbc9625b: "iommu/arm-smmu: Make use of the
>> iommu_register interface" from Feb 1, 2017, lea
On 22/02/17 23:39, Bjorn Helgaas wrote:
> [+cc Joerg, iommu list]
>
> On Wed, Feb 22, 2017 at 03:44:53PM -0500, Sinan Kaya wrote:
>> On 2/22/2017 1:44 PM, Bjorn Helgaas wrote:
>>> There is no way for a driver to say "I only need this memory BAR and
>>> not the other ones." The reason is because t
On 23/02/17 08:17, Marek Szyprowski wrote:
> This patch consolidates almost the same code used in iova_insert_rbtree()
> and __alloc_and_insert_iova_range() functions. There is no functional change.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/iommu/iova.c | 85
> +++-
ed iova tree or incorrect calls.
Thanks Marek!
Tested-by: Robin Murphy
Reviewed-by: Robin Murphy
> Signed-off-by: Marek Szyprowski
> ---
> v2:
> - replaced BUG() with WARN_ON(1) as suggested by Robin Murphy
>
> v1:
> - initial version
&
e reminder. I'll send an rc1-based version out next week to
reboot the discussion.
Robin.
>
> Thanks,
> Nipun
>
>
>> -Original Message-
>> From: Nipun Gupta
>> Sent: Sunday, December 18, 2016 2:37
>> To: Robin Murphy ; iommu@lists.linux-
&
On 06/03/17 13:58, Robert Richter wrote:
> The ARM SMMU detection especially depends from system firmware. For
> better diagnostic, log the detected type in dmesg.
This paragraph especially depends from grammar. I think.
> The smmu type's name is now stored in struct arm_smmu_type and ACPI
> code
On 01/03/17 17:42, Rob Clark wrote:
> An iommu driver for Qualcomm "B" family devices which do not completely
> implement the ARM SMMU spec.
Is that actually true, or is it just that it's a compliant SMMU on which
firmware has set SCR1.GASRAE? (which makes the global address space
secure-access-on
aving. And at worst, if the
firmware is wrong enough to have not mapped something we actually try to
use, the resulting out-of-bounds access will hopefully provide a much
more obvious clue.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 4 +++-
1 file changed, 3 insertions(+), 1 del
s somewhat of a fix in its own right, in that it's really an
entirely unrelated thing which came up in parallel, but happens to
be inherent to code I'm touching here anyway.
Robin.
Robin Murphy (4):
iommu/arm-smmu: Handle size mismatches better
iommu/arm-smmu: Simplify ASID/VMID handl
arm_smmu_cfg; let's just
precalculate an ASID/VMID, plop it in there, and tidy up the users
accordingly. We'd also need something like this anyway if we ever get
near to thinking about SVM, so it's no bad thing.
Signed-off-by: Robin Murphy
---
drivers/iommu/
round so that we just
maintain the CB_BASE address directly.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 0b64852baa6a..c8aafe3
o the already unwieldy
monolithic TLB maintenance ops, break them up into smaller, neater,
functions which we can then mix and match as appropriate.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 156 ++-
1 file changed, 100 insertions(+
. for MMU-500 configurations where the appended TBU
number gets in the way unnecessarily). Let's add a new property to allow
a single global mask value to better fit the latter situation.
Tested-by: Nipun Gupta
Signed-off-by: Robin Murphy
---
Time to rekindle the discussion about wheth
On 07/03/17 14:06, Robert Richter wrote:
> On 06.03.17 18:22:08, Robin Murphy wrote:
>> On 06/03/17 13:58, Robert Richter wrote:
>>> The ARM SMMU detection especially depends from system firmware. For
>>> better diagnostic, log the detected type in dmesg.
>>
>
Hi Magnus,
On 08/03/17 11:01, Magnus Damm wrote:
> From: Magnus Damm
>
> Introduce struct ipmmu_features to track various hardware
> and software implementation changes inside the driver for
> different kinds of IPMMU hardware. Add use_ns_alias_offset
> as a first example of a feature to control
On 08/03/17 11:01, Magnus Damm wrote:
> From: Magnus Damm
>
> Add support for up to 8 contexts. Each context is mapped to one
> domain. One domain is assigned one or more slave devices. Contexts
> are allocated dynamically and slave devices are grouped together
> based on which IPMMU device they
On 08/03/17 11:02, Magnus Damm wrote:
> From: Magnus Damm
>
> Write IMCTR both in the root device and the leaf node.
>
> Signed-off-by: Magnus Damm
> ---
>
> Changes since V2:
> - None
>
> Changes since V1:
> - None
>
> drivers/iommu/ipmmu-vmsa.c | 17 ++---
> 1 file chang
On 07/03/17 03:17, Magnus Damm wrote:
> From: Magnus Damm
>
> Not all architectures have an iommu member in their archdata, so
> use #ifdefs support build with COMPILE_TEST on any architecture.
I have a feeling I might be repeating myself, but ipmmu_vmsa_archdata
looks to be trivially convertibl
On 07/03/17 03:17, Magnus Damm wrote:
> From: Magnus Damm
>
> Introduce an alternative set of iommu_ops suitable for 64-bit ARM
> as well as 32-bit ARM when CONFIG_IOMMU_DMA=y. Also adjust the
> Kconfig to depend on ARM or IOMMU_DMA. Initialize the device
> from ->xlate() when CONFIG_IOMMU_DMA=y.
On 08/03/17 18:58, Jean-Philippe Brucker wrote:
[...]
>> static const struct iommu_ops
>> -*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node *bridge_np)
>> +*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
>> {
>> const struct iommu_ops *ops;
>> str
On 09/03/17 09:52, sricharan wrote:
> Hi Robin,
>
>> On 08/03/17 18:58, Jean-Philippe Brucker wrote:
>> [...]
static const struct iommu_ops
-*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node
*bridge_np)
+*of_pci_iommu_init(struct pci_dev *pdev, struct device_nod
On 09/03/17 03:44, Magnus Damm wrote:
> Hi Robin,
>
> On Wed, Mar 8, 2017 at 9:48 PM, Robin Murphy wrote:
>> On 07/03/17 03:17, Magnus Damm wrote:
>>> From: Magnus Damm
>>>
>>> Not all architectures have an iommu member in their archdata, so
>>
On 09/03/17 12:02, Robert Richter wrote:
> On 07.03.17 18:41:33, Robin Murphy wrote:
>> On 07/03/17 14:06, Robert Richter wrote:
>>> On 06.03.17 18:22:08, Robin Murphy wrote:
>>>> On 06/03/17 13:58, Robert Richter wrote:
>>>>> The ARM SMMU detection
iommu-dma).
Fixes: d30ddcaa7b02 ("iommu: Add a new type field in iommu_resv_region")
CC: Eric Auger
CC: Alex Williamson
CC: David Woodhouse
CC: k...@vger.kernel.org
Signed-off-by: Robin Murphy
---
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/arm-smmu-v3.c | 2 +-
dr
1 - 100 of 3517 matches
Mail list logo
