From: Magnus Damm
Update the IPMMU DT binding documentation to include the r8a77965 compat
string for the IPMMU devices included in the R-Car M3-N SoC.
Signed-off-by: Magnus Damm
---
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1 +
1 file changed, 1 insertion(+)
--- 0
On Mon, 2018-03-19 at 13:15 +0100, Sebastian Andrzej Siewior wrote:
> On 2018-03-17 16:43:39 [-0500], Scott Wood wrote:
> > If that's worth the lock dropping then fine (though why does only
> > one
> > of the two allocations use GFP_KERNEL?), but it doesn't need to be
> > a
>
> That was a mistake,
On Mon, Mar 19, 2018 at 06:01:41PM +, Catalin Marinas wrote:
> I don't particularly like maintaining an arm64-specific dma-direct.h
> either but arm64 seems to be the only architecture that needs to
> potentially force a bounce when cache_line_size() > ARCH_DMA_MINALIGN
> and the device is non-
On Mon, Mar 19, 2018 at 05:03:43PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 19, 2018 at 03:48:33PM +, Will Deacon wrote:
> > Why can't we just resolve the conflict by adding the underscores?
>
> We can solve the conflict easily that way. But that's not the point.
>
> The point is that I
On Mon, Mar 19, 2018 at 05:03:43PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 19, 2018 at 03:48:33PM +, Will Deacon wrote:
> > Why can't we just resolve the conflict by adding the underscores?
>
> We can solve the conflict easily that way. But that's not the point.
>
> The point is that I
On Thu, 15 Mar 2018 14:18:54 +0100
Joerg Roedel wrote:
> On Thu, Feb 15, 2018 at 08:38:11AM -0800, Jacob Pan wrote:
> > Just wondering if your concern is on the implementation or the
> > debugfs idea in general. Perhaps have some common IOMMU debugfs?
>
> My concern mainly is that we add inter
On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
wrote:
Hi Geert,
This essentially removes this commit
commit 1c8cb409491403036919dd1c6b45013dc8835a44
Author: Sudip Mukherjee
Date: Wed Aug 3 13:45:46 2016 -0700
drivers/fpga/Kconfig: fix build failure
While building m32r allmodco
On Mon, Mar 19, 2018 at 03:48:33PM +, Will Deacon wrote:
> Why can't we just resolve the conflict by adding the underscores?
We can solve the conflict easily that way. But that's not the point.
The point is that I've been fighting hard to consolidate dma code
given that the behavior really i
On Mon, Mar 19, 2018 at 03:37:20PM +, Robin Murphy wrote:
> On 19/03/18 15:24, Christoph Hellwig wrote:
> >On Mon, Mar 19, 2018 at 03:19:04PM +, Robin Murphy wrote:
> >>As a heads-up, I've just realised there's now a silent (but build-breaking)
> >>conflict with the current arm64 queue brew
On 19/03/18 15:24, Christoph Hellwig wrote:
On Mon, Mar 19, 2018 at 03:19:04PM +, Robin Murphy wrote:
As a heads-up, I've just realised there's now a silent (but build-breaking)
conflict with the current arm64 queue brewing here, as we've unfortunately
had to reintroduce ARCH_HAS_PHYS_TO_DMA
On Mon, Mar 19, 2018 at 11:27:37AM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 19, 2018 at 11:38:12AM +0100, Christoph Hellwig wrote:
> > Hi all,
> >
> > this series switches the x86 code the the dma-direct implementation
> > for direct (non-iommu) dma and the generic swiotlb ops. This incl
On Mon, Mar 19, 2018 at 11:38:12AM +0100, Christoph Hellwig wrote:
> Hi all,
>
> this series switches the x86 code the the dma-direct implementation
> for direct (non-iommu) dma and the generic swiotlb ops. This includes
> getting rid of the special ops for the AMD memory encryption case and
> th
On Mon, Mar 19, 2018 at 03:19:04PM +, Robin Murphy wrote:
> As a heads-up, I've just realised there's now a silent (but build-breaking)
> conflict with the current arm64 queue brewing here, as we've unfortunately
> had to reintroduce ARCH_HAS_PHYS_TO_DMA as a means of being safe against an
>
On 19/03/18 10:38, Christoph Hellwig wrote:
Give the basic phys_to_dma and dma_to_phys helpers a __-prefix and add
the memory encryption mask to the non-prefixed versions. Use the
__-prefixed versions directly instead of clearing the mask again in
various places.
Signed-off-by: Christoph Hellwi
On Mon, 19 Mar 2018, Christoph Hellwig wrote:
> Hi all,
>
> this series switches the x86 code the the dma-direct implementation
> for direct (non-iommu) dma and the generic swiotlb ops. This includes
> getting rid of the special ops for the AMD memory encryption case and
> the STA2x11 SOC. The
On 3/19/2018 5:38 AM, Christoph Hellwig wrote:
> With that in place the generic dma-direct routines can be used to
> allocate non-encrypted bounce buffers, and the x86 SEV case can use
> the generic swiotlb ops including nice features such as using CMA
> allocations.
>
> Note that I'm not too happ
On 3/19/2018 5:38 AM, Christoph Hellwig wrote:
> Give the basic phys_to_dma and dma_to_phys helpers a __-prefix and add
> the memory encryption mask to the non-prefixed versions. Use the
> __-prefixed versions directly instead of clearing the mask again in
> various places.
>
> Signed-off-by: Chr
Hi Geert,
On Fri, 16 Mar 2018 14:51:47 +0100
Geert Uytterhoeven wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symb
On 03/16/2018 02:51 PM, Geert Uytterhoeven wrote:
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols a
On 3/19/2018 5:38 AM, Christoph Hellwig wrote:
> Now that set_memory_decrypted is always available we can just call it
> directly.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Tom Lendacky
> ---
> arch/x86/include/asm/mem_encrypt.h | 2 --
> arch/x8
On 3/19/2018 5:38 AM, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Tom Lendacky
> ---
> include/linux/set_memory.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/set_memory.h b/include/linu
On 3/19/2018 5:38 AM, Christoph Hellwig wrote:
> Hi all,
>
> this series switches the x86 code the the dma-direct implementation
> for direct (non-iommu) dma and the generic swiotlb ops. This includes
> getting rid of the special ops for the AMD memory encryption case and
> the STA2x11 SOC. The
On 3/19/2018 5:39 AM, Christoph Hellwig wrote:
> Can you test and review the V3 of the series I just sent out?
> We reall should get it into linux-next ASAP.
Can do. I'll get back to you on V3 thread with the results.
Thanks,
Tom
>
___
iommu mailing
> From: Shameerali Kolothum Thodi
> [mailto:shameerali.kolothum.th...@huawei.com]
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Monday, March 19, 2018 7:52 AM
> > To: Shameerali Kolothum Thodi
> ;
> > alex.william...@redhat.com; eric.au...@redhat.co
On 2018-03-17 16:43:39 [-0500], Scott Wood wrote:
> If that's worth the lock dropping then fine (though why does only one
> of the two allocations use GFP_KERNEL?), but it doesn't need to be a
That was a mistake, I planned to keep both as GFP_KERNEL.
> raw lock if the non-allocating users are sepa
> From: Shameerali Kolothum Thodi
> [mailto:shameerali.kolothum.th...@huawei.com]
>
> Hi Kevin,
>
> Thanks for taking a look at this series.
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: Monday, March 19, 2018 8:29 AM
> > To: Shameerali Kolothum T
Hi Jean,
[...]
> @@ -3168,6 +3260,13 @@ static int arm_smmu_device_probe(struct
> platform_device *pdev)
> if (ret)
> return ret;
>
> + if (smmu->features & (ARM_SMMU_FEAT_STALLS | ARM_SMMU_FEAT_PRI)) {
> + smmu->faultq_nb.notifier_call = arm_smmu_flush_queue
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Monday, March 19, 2018 7:52 AM
> To: Shameerali Kolothum Thodi ;
> alex.william...@redhat.com; eric.au...@redhat.com;
> pmo...@linux.vnet.ibm.com
> Cc: k...@vger.kernel.org; linux-ker...@vger.kernel.org; xuwei
Hi Kevin,
Thanks for taking a look at this series.
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Monday, March 19, 2018 8:29 AM
> To: Shameerali Kolothum Thodi ;
> alex.william...@redhat.com; eric.au...@redhat.com;
> pmo...@linux.vnet.ibm.com
> Cc: k...@vg
Now that set_memory_decrypted is always available we can just call it
directly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/mem_encrypt.h | 2 --
arch/x86/mm/mem_encrypt.c | 9 -
lib/swiotlb.c | 12 ++--
Use the dma_direct_* helpers and cleanup the code flow.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 62 -
2 files changed, 17 insertions(+), 46 deletions(-)
diff --git a/drivers/iommu/Kconfig
All dma_ops implementations used on x86 now take care of setting their own
required GFP_ masks for the allocation. And given that the common code
now clears harmful flags itself that means we can stop the flags in all
the iommu implementations as well.
Signed-off-by: Christoph Hellwig
---
arch/
Give the basic phys_to_dma and dma_to_phys helpers a __-prefix and add
the memory encryption mask to the non-prefixed versions. Use the
__-prefixed versions directly instead of clearing the mask again in
various places.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-direct.h
Signed-off-by: Christoph Hellwig
Reviewed-by: Konrad Rzeszutek Wilk
---
include/linux/set_memory.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
index e5140648f638..da5178216da5 100644
--- a/include/linux/set_memory.h
++
Can you test and review the V3 of the series I just sent out?
We reall should get it into linux-next ASAP.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
With that in place the generic dma-direct routines can be used to
allocate non-encrypted bounce buffers, and the x86 SEV case can use
the generic swiotlb ops including nice features such as using CMA
allocations.
Note that I'm not too happy about using sev_active() in dma-direct, but
I couldn't co
This cleans up the code a lot by removing duplicate logic.
Signed-off-by: Christoph Hellwig
Tested-by: Joerg Roedel
Acked-by: Joerg Roedel
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/amd_iommu.c | 68 +++
2 files changed, 22 insertions(+), 47
The generic swiotlb dma ops were based on the x86 ones and provide
equivalent functionality, so use them.
Also fix the sta2x11 case. For that SOC the dma map ops need an
additional physical to dma address translations. For swiotlb buffers
that is done throught the phys_to_dma helper, but the sta
We want to phase out looking at the magic GFP_DMA flag in the dma mapping
routines, so switch the gart driver to use the coherent_dma_mask instead,
which is used to select the GFP_DMA flag in the caller.
Signed-off-by: Christoph Hellwig
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/kernel/amd
Unused now that everyone uses swiotlb_{alloc,free}.
Signed-off-by: Christoph Hellwig
---
include/linux/swiotlb.h | 8
lib/swiotlb.c | 38 --
2 files changed, 46 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
in
This gains support for CMA allocations for the force_iommu case, and
cleans up the code a bit.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 36 ++--
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/arch/x86/kernel/amd_gart_64
These days all devices (including the ISA fallback device) have a coherent
DMA mask set, so remove the workaround.
Signed-off-by: Christoph Hellwig
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/include/asm/dma-mapping.h | 18 ++
arch/x86/kernel/pci-dma.c | 10
The generic dma-direct implementation is now functionally equivalent to
the x86 nommu dma_map implementation, so switch over to using it. That
includes switching from using x86_dma_supported in various iommu drivers
to use dma_direct_supported instead, which provides the same
functionality.
Signe
There were only a few Pentium Pro multiprocessors systems where this
errata applied. They are more than 20 years old now, and we've slowly
dropped places where put the workarounds in and discouraged anyone
from enabling the workaround.
Get rid of it for good.
Signed-off-by: Christoph Hellwig
Rev
Hi all,
this series switches the x86 code the the dma-direct implementation
for direct (non-iommu) dma and the generic swiotlb ops. This includes
getting rid of the special ops for the AMD memory encryption case and
the STA2x11 SOC. The generic implementations are based on the x86
code, so they
Hi Jean,
vfio can be compiled as module, however you use some functions which are not
exported.
comment inline:
[...]
> Add two new ioctl for VFIO containers. VFIO_IOMMU_BIND_PROCESS creates a
> bond between a container and a process address space, identified by a
> device-specific ID named PASI
> From: Shameer Kolothum
> Sent: Friday, March 16, 2018 12:35 AM
>
> This series introduces an iova list associated with a vfio
> iommu. The list is kept updated taking care of iommu apertures,
> and reserved regions. Also this series adds checks for any conflict
> with existing dma mappings whene
> From: Shameer Kolothum
> Sent: Friday, March 16, 2018 12:35 AM
>
> This retrieves the reserved regions associated with dev group and
> checks for conflicts with any existing dma mappings. Also update
> the iova list excluding the reserved regions.
>
> Signed-off-by: Shameer Kolothum
>
> ---
>
48 matches
Mail list logo
