On Mon, 27 Aug 2018 11:56:24 +0100,
Heiko Stuebner wrote:
>
> In the iommu's shutdown handler we disable runtime-pm which could
> result in the irq-handler running unclocked and since commit
> 3fc7c5c0cff3 ("iommu/rockchip: Handle errors returned from PM framework")
> we warn about that fact.
On Thu, Sep 20, 2018 at 11:08 AM, Christoph Hellwig wrote:
> On Thu, Sep 20, 2018 at 10:44:55AM -0700, Max Filippov wrote:
>> Hi Christoph,
>>
>> On Thu, Sep 20, 2018 at 10:15 AM, Christoph Hellwig wrote:
>> > This reverts commit 6137e4166004e2ec383ac05d5ca15831f4668806.
>> >
>> > We explicitly c
Instead of rejecting devices with a too small bus_dma_mask we can handle
by taking the bus dma_mask into account for allocations and bounce
buffering decisions.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 3 ++-
kernel/dma/direct.c| 21 +++--
2 file
This is somewhat modelled after the powerpc version, and differs from
the legacy fallback in use fls64 instead of pointlessly splitting up the
address into low and high dwords and in that it takes (__)phys_to_dma
into account.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 1
This way an architecture with less than 4G of RAM can support dma_mask
smaller than 32-bit without a ZONE_DMA. Apparently that is a common
case on powerpc.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 28
1 file changed, 16 insertions(+), 12 deletions(
We need to take the DMA offset and encryption bit into account when
selecting a zone. User the opportunity to factor out the zone
selection into a helper for reuse.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 31 +--
1 file changed, 21 insertions(+), 1
This save some duplication for ia64, and makes the interface more
general. In the long run we want each dma_map_ops instance to fill this
out, but this will take a little more prep work.
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/dma-mapping.h | 2 --
arch/ia64/include/asm/mac
Hi all,
the dma_get_required_mask dma API implementation has always been a little
odd, in that we by default don't wire it up struct dma_map_ops, but
instead hard code a default implementation. powerpc and ia64 override
this default and either call a method or otherwise duplicate the default.
Th
On Thu, Sep 20, 2018 at 10:44:55AM -0700, Max Filippov wrote:
> Hi Christoph,
>
> On Thu, Sep 20, 2018 at 10:15 AM, Christoph Hellwig wrote:
> > This reverts commit 6137e4166004e2ec383ac05d5ca15831f4668806.
> >
> > We explicitly clear GFP_HIGHMEM from the allowed dma flags at the beginning
> > of
Hi Christoph,
On Thu, Sep 20, 2018 at 10:15 AM, Christoph Hellwig wrote:
> This reverts commit 6137e4166004e2ec383ac05d5ca15831f4668806.
>
> We explicitly clear GFP_HIGHMEM from the allowed dma flags at the beginning
> of the function (and the generic dma_alloc_attr function calling us does the
>
On 03/09/18 07:01, Yong Wu wrote:
MediaTek extend the arm v7s descriptor to support the dram over 4GB.
In the mt2712 and mt8173, it's called "4GB mode", the physical address
is from 0x4000_ to 0x1_3fff_, but from EMI point of view, it
is remapped to high address from 0x1__ to 0x1
When a recoverable page fault is handled by the fault workqueue, find the
associated mm and call handle_mm_fault.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/io-pgfault.c | 86 +-
1 file changed, 84 insertions(+), 2 deletions(-)
diff --git a/driver
Provide an API for allocating PASIDs and populating them manually. To ease
cleanup and factor allocation code, reuse the io_mm structure for private
PASID. Private io_mm has a NULL mm_struct pointer, and cannot be bound to
multiple devices. The mm_alloc() IOMMU op must now check if the mm
argument
Let users call iommu_sva_init_device() with the IOMMU_SVA_FEAT_IOPF flag,
that enables the I/O Page Fault queue. The IOMMU driver checks is the
device supports a form of page fault, in which case they add the device to
a fault queue. If the device doesn't support page faults, the IOMMU driver
abort
When creating an io_mm structure, register an MMU notifier that informs
us when the virtual address space changes and disappears.
Add a new operation to the IOMMU driver, mm_invalidate, called when a
range of addresses is unmapped to let the IOMMU driver send ATC
invalidations. mm_invalidate canno
Some systems allow devices to handle I/O Page Faults in the core mm. For
example systems implementing the PCI PRI extension or Arm SMMU stall
model. Infrastructure for reporting these recoverable page faults was
recently added to the IOMMU core for SVA virtualisation. Add a page fault
handler for h
The fault handler will need to find an mm given its PASID. This is the
reason we have an IDR for storing address spaces, so hook it up.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/iommu-sva.c | 26 ++
include/linux/iommu.h | 7 +++
2 files changed, 33
When an mm exits, devices that were bound to it must stop performing DMA
on its PASID. Let device drivers register a callback to be notified on mm
exit. Add the callback to the sva_param structure attached to struct
device.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/iommu-sva.c | 10
Allocate IOMMU mm structures and bind them to devices. Four operations are
added to IOMMU drivers:
* mm_alloc(): to create an io_mm structure and perform architecture-
specific operations required to grab the process (for instance on ARM,
pin down the CPU ASID so that the process doesn't get a
Add bind() and unbind() operations to the IOMMU API. Bind() returns a
PASID that drivers can program in hardware, to let their devices access an
mm. This patch only adds skeletons for the device driver API, most of the
implementation is still missing.
Signed-off-by: Jean-Philippe Brucker
---
dri
Shared Virtual Addressing (SVA) provides a way for device drivers to bind
process address spaces to devices. This requires the IOMMU to support page
table format and features compatible with the CPUs, and usually requires
the system to support I/O Page Faults (IOPF) and Process Address Space ID
(PA
This is version 3 of the core changes for Shared Virtual Addressing in
the IOMMU. It provides an API for sharing process address spaces with
devices, using for example PCI PASID and PRI.
This time I didn't append the VFIO and SMMUv3 example users. A smaller
series is easier for me to manage and ma
On Tue, 18 Sep 2018 16:24:38 +0200
Eric Auger wrote:
> From: Jacob Pan
>
> In virtualization use case, when a guest is assigned
> a PCI host device, protected by a virtual IOMMU on a guest,
> the physical IOMMU must be programmed to be consistent with
> the guest mappings. If the physical IOMMU
ZONE_DMA is intended for magic < 32-bit pools (usually ISA DMA), which
isn't required on xtensa. Move all the non-highmem memory into
ZONE_NORMAL instead to match other architectures.
Signed-off-by: Christoph Hellwig
---
arch/xtensa/Kconfig | 3 ---
arch/xtensa/mm/init.c | 2 +-
2 files chang
Use the generic helpers for dma allocation instead of opencoding them
with slightly less bells and whistles.
Signed-off-by: Christoph Hellwig
---
arch/xtensa/kernel/pci-dma.c | 48 ++--
1 file changed, 13 insertions(+), 35 deletions(-)
diff --git a/arch/xtensa/ke
This reverts commit 6137e4166004e2ec383ac05d5ca15831f4668806.
We explicitly clear GFP_HIGHMEM from the allowed dma flags at the beginning
of the function (and the generic dma_alloc_attr function calling us does the
same!), so this code just adds dead wood.
Signed-off-by: Christoph Hellwig
---
a
Hi Chris and Max,
this small series has a few tweaks to the xtensa dma-mapping code.
It is against the dma-mapping tree:
git://git.infradead.org/users/hch/dma-mapping.git for-next
Gitweb:
http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/for-next
_
On 8/16/18 8:23 PM, Robin Murphy wrote:
On 15/08/18 20:56, Dmitry Osipenko wrote:
On Friday, 3 August 2018 18:43:41 MSK Robin Murphy wrote:
On 02/08/18 19:24, Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse
On Thu, 20 Sep 2018 14:14:26 +0100
Robin Murphy wrote:
> Document that the default for "iommu.passthrough" is now configurable.
>
> Fixes: 58d1131777a4 ("iommu: Add config option to set passthrough as default")
> Signed-off-by: Robin Murphy
> ---
>
> Joerg, Jon, as a pure doc fix I'll leave it
> A couple random cleanups I stumbled upon when doing dma related work.
Christoph,
Thanks. Applied. Will send pull request for next merge window.
-Tony
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/l
All we need is to wire up .flush_iotlb_all properly and implement the
domain attribute, and iommu-dma and io-pgtable will do the rest for us.
The only real subtlety is documenting the barrier semantics we're
introducing between io-pgtable and the drivers for non-strict flushes.
Signed-off-by: Robi
From: Zhen Lei
Add a generic command line option to enable lazy unmapping via IOVA
flush queues, which will initally be suuported by iommu-dma. This echoes
the semantics of "intel_iommu=strict" (albeit with the opposite default
value), but in the driver-agnostic fashion of "iommu.passthrough".
S
From: Zhen Lei
Now that io-pgtable knows how to dodge strict TLB maintenance, all
that's left to do is bridge the gap between the IOMMU core requesting
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE for default domains, and showing the
appropriate IO_PGTABLE_QUIRK_NON_STRICT flag to alloc_io_pgtable_ops().
Sig
As for LPAE, it's simply a case of skipping the leaf invalidation for a
regular unmap, and ensuring that the one in split_blk_unmap() is paired
with an explicit sync ASAP rather than relying on one which might only
eventually happen way down the line.
Signed-off-by: Robin Murphy
---
v8: Do this
From: Zhen Lei
Non-strict mode is simply a case of skipping 'regular' leaf TLBIs, since
the sync is already factored out into ops->iotlb_sync at the core API
level. Non-leaf invalidations where we change the page table structure
itself still have to be issued synchronously in order to maintain wa
From: Zhen Lei
With the flush queue infrastructure already abstracted into IOVA
domains, hooking it up in iommu-dma is pretty simple. Since there is a
degree of dependency on the IOMMU driver knowing what to do to play
along, we key the whole thing off a domain attribute which will be set
on defa
From: Zhen Lei
.flush_iotlb_all is currently stubbed to arm_smmu_iotlb_sync() since the
only time it would ever need to actually do anything is for callers
doing their own explicit batching, e.g.:
iommu_unmap_fast(domain, ...);
iommu_unmap_fast(domain, ...);
iommu_iotlb_f
Hi all,
Hopefully this is the last spin of the series - I've now dropped my light
touch and fixed up all the various prose text, plus implemented the proper
quirk support for short-descriptor because it's actually just a trivial
cut-and-paste job.
Robin.
Robin Murphy (2):
iommu/io-pgtable-arm
On Wed, 19 Sep 2018 02:22:03 +
"Tian, Kevin" wrote:
> > From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> > Sent: Tuesday, September 18, 2018 11:47 PM
> >
> > On 14/09/2018 22:04, Jacob Pan wrote:
> > >> This example only needs to modify first-level translation, and
> >
On Thu, Sep 20, 2018 at 01:55:43PM +0800, Kenneth Lee wrote:
> On Tue, Sep 18, 2018 at 09:03:14AM -0400, Jerome Glisse wrote:
> > On Tue, Sep 18, 2018 at 02:00:14PM +0800, Kenneth Lee wrote:
> > > On Mon, Sep 17, 2018 at 08:37:45AM -0400, Jerome Glisse wrote:
> > > > On Mon, Sep 17, 2018 at 04:39:4
Document that the default for "iommu.passthrough" is now configurable.
Fixes: 58d1131777a4 ("iommu: Add config option to set passthrough as default")
Signed-off-by: Robin Murphy
---
Joerg, Jon, as a pure doc fix I'll leave it to your discretion as to
whose tree is most appropriate (it shouldn't
On 17/09/2018 12:20, John Garry wrote:
On 14/09/2018 13:48, Will Deacon wrote:
Hi Robin,
Hi Robin,
I just spoke with Dongdong and we will test this version also so that we
may provide a "Tested-by" tag.
I tested this, so for series:
Tested-by: John Garry
Thanks,
John
Thanks,
John
On
On Wed, Sep 5, 2018 at 2:04 PM, Sedat Dilek wrote:
> Hi Joerg,
>
> "intel_ioomu=on" was working fine here on my ThinkPad T470 with
> debian/testing AMD64 with Linux v4.17.y and v4.18.y.
>
> With testing Linux v4.19-rc1 and v4.19-rc2 my machine is not booting -
> black screen.
> These kernels are b
On 20/09/18 06:54, Yong Wu wrote:
Hi Robin,
Could you help take a look at this patch since I changed the v7s
here?
Thanks.
Sorry, I did have a very quick skim through this series when it landed
in my inbox but I've not yet found the chance to go through it properly.
Since I am actual
Hi Will,
On Wed, Jun 27, 2018 at 10:07 PM Will Deacon wrote:
>
> Hi Vivek,
>
> On Tue, Jun 19, 2018 at 02:04:44PM +0530, Vivek Gautam wrote:
> > On Fri, Jun 15, 2018 at 10:22 PM, Will Deacon wrote:
> > > On Fri, Jun 15, 2018 at 04:23:29PM +0530, Vivek Gautam wrote:
> > >> Qualcomm SoCs have an a
On Thu, Sep 20, 2018 at 1:05 AM Jordan Crouse wrote:
>
> On Tue, Jul 24, 2018 at 03:13:37PM +0530, Vivek Gautam wrote:
> > Hi Will,
> >
> >
> > On Wed, Jun 27, 2018 at 10:07 PM, Will Deacon wrote:
> > > Hi Vivek,
> > >
> > > On Tue, Jun 19, 2018 at 02:04:44PM +0530, Vivek Gautam wrote:
> > >> On
The original form of these was added (to the HP zx1 platform only) by
the following bitkeeper commit (by the way of the historic.git tree):
commit 66b99421d118a5ddd98a72913670b0fcf0a38d45
Author: Andrew Morton
Date: Sat Mar 13 17:05:37 2004 -0800
[PATCH] DMA: Fill gaping hole in DMA API in
These do nothing but duplicating an assert that would have triggered
earlier on setting the dma mask, so remove them.
Signed-off-by: Christoph Hellwig
---
arch/ia64/sn/pci/pci_dma.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/arch/ia64/sn/pci/pci_dma.c b/arc
ia64 currently explicitly assigns it to dma_ops, but that same work is
already done by intel_iommu_init a little later, so we can remove the
duplicate assignment and mark the variable static.
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/pci-dma.c | 4
drivers/iommu/intel-iommu.c |
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/iommu.h | 1 -
arch/ia64/kernel/pci-dma.c| 6 --
2 files changed, 7 deletions(-)
diff --git a/arch/ia64/include/asm/iommu.h b/arch/ia64/include/asm/iommu.h
index 5397e5aa3704..7429a72f3f92 100644
--- a/arch/ia64/include/asm/iommu
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/iommu.h | 1 -
arch/ia64/kernel/pci-dma.c| 5 -
2 files changed, 6 deletions(-)
diff --git a/arch/ia64/include/asm/iommu.h b/arch/ia64/include/asm/iommu.h
index 156b9d8e1932..5397e5aa3704 100644
--- a/arch/ia64/include/asm/iommu.
A couple random cleanups I stumbled upon when doing dma related work.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks like copy and paste from x86 that never actually got used.
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/pci-dma.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index b5df084c0af4..50b6ad282a90 100644
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/pci-dma.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/ia64/kernel/pci-dma.c b/arch/ia64/kernel/pci-dma.c
index 3c2884bef3d4..924966e5aa25 100644
--- a/arch/ia64/kernel/pci-dma.c
+++ b/arch/ia64/kernel/pci-dma.c
@@ -15,9 +15,6 @@
The generic dma_direct_supported helper already used by intel-iommu on
x86 does a better job than the ia64 reimplementation.
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/pci-dma.c | 13 -
drivers/iommu/intel-iommu.c | 2 --
2 files changed, 15 deletions(-)
diff --git a/ar
No actually used anywhere.
Signed-off-by: Christoph Hellwig
---
arch/ia64/kernel/efi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 9c09bf390cce..f77d80edddfe 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -842,7 +8
I've pulled this into the dma-mapping for-next tree now to make
progress. Any further review comments should be dealt with in
incremental patches.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/
57 matches
Mail list logo
