Hi,
On 8/14/19 9:38 PM, Joerg Roedel wrote:
From: Joerg Roedel
Set the default domain-type at runtime, not at compile-time.
This keeps default domain type setting in one place when we
have to change it at runtime.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 23 +++--
Hi Joerg,
On 8/14/19 4:38 PM, Joerg Roedel wrote:
Hi Lu Baolu,
On Tue, Jul 30, 2019 at 12:52:26PM +0800, Lu Baolu wrote:
* iommu_bounce_map(dev, addr, paddr, size, dir, attrs)
- Map a buffer start at DMA address @addr in bounce page
manner. For buffer parts that doesn't cross a whole
On 2019/8/14 19:14, Will Deacon wrote:
> Hi,
>
> I've been struggling with the memory ordering requirements here. More below.
>
> On Thu, Aug 01, 2019 at 08:20:40PM +0800, Zhen Lei wrote:
>> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a
>> smmu domain does not conta
When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a
smmu domain does not contain any ats master, the operations of
arm_smmu_atc_inv_to_cmd() and lock protection in arm_smmu_atc_inv_domain()
are always executed. This will impact performance, especially in
multi-core and stress
v1 --> v2:
1. change the type of nr_ats_masters from atomic_t to int, and move its
ind/dec operation from arm_smmu_enable_ats()/arm_smmu_disable_ats() to
arm_smmu_attach_dev()/arm_smmu_detach_dev(), and protected by
"spin_lock_irqsave(&smmu_domain->devices_lock, flags);"
Zhen Lei (2):
i
Once a master has been added into smmu_domain->devices, it may immediately
be scaned in arm_smmu_unmap()-->arm_smmu_atc_inv_domain(). From a logical
point of view, the master should be added into smmu_domain after it has
been completely initialized.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-
Hi,
On 8/14/19 9:38 PM, Joerg Roedel wrote:
From: Joerg Roedel
Introduce a subsys_initcall for IOMMU code and use it to
print the default domain type at boot.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 30 +-
1 file changed, 29 insertions(+), 1 del
Hi,
On 8/14/19 9:38 PM, Joerg Roedel wrote:
From: Joerg Roedel
Introduce an extensible concept to remember when certain
configuration settings for the IOMMU code have been set on
the kernel command line.
This will be used later to prevent overwriting these
settings with other defaults.
Signe
Hi,
On 8/14/19 9:38 PM, Joerg Roedel wrote:
From: Joerg Roedel
This variable has no users anymore. Remove it and tell the
IOMMU code via its new functions about requested DMA modes.
Signed-off-by: Joerg Roedel
This will also simplify the procedures in iommu_probe_device() on x86
platforms.
Hi Joerg,
On 8/14/19 9:38 PM, Joerg Roedel wrote:
From: Joerg Roedel
Get rid of the iommu_pass_through variable and request
passthrough mode via the new iommu core function.
Signed-off-by: Joerg Roedel
Looks good to me.
Reviewed-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 2 +-
1
On Wed, Aug 14, 2019 at 02:20:31PM -0700, Ralph Campbell wrote:
>
> On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Many places in the kernel have a flow where userspace will create some
> > object and that object will need to connect to the subsystem's
> > mmu_notifi
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This series introduces a new registration flow for mmu_notifiers based on
the idea that the user would like to get a single refcounted piece of
memory for a mm, keyed to its use.
For instance many users of mmu_notifiers use an i
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
mmu_notifier_unregister_no_release() and mmu_notifier_call_srcu() no
longer have any users, they have all been converted to use
mmu_notifier_put().
So delete this difficult to use interface.
Signed-off-by: Jason Gunthorpe
Re
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This is a significant simplification, it eliminates all the remaining
'hmm' stuff in mm_struct, eliminates krefing along the critical notifier
paths, and takes away all the ugly locking and abuse of page_table_lock.
mmu_notifier
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Many places in the kernel have a flow where userspace will create some
object and that object will need to connect to the subsystem's
mmu_notifier subscription for the duration of its lifetime.
In this case the subsystem is usua
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
A prior commit e0f3c3f78da2 ("mm/mmu_notifier: init notifier if necessary")
made an attempt at doing this, but had to be reverted as calling
the GFP_KERNEL allocator under the i_mmap_mutex causes deadlock, see
commit 35cfa2b0b491
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This simplifies the code to not have so many one line functions and extra
logic. __mmu_notifier_register() simply becomes the entry point to
register the notifier, and the other one calls it under lock.
Also add a lockdep_assert
On Thu, 18 Jul 2019 10:35:37 +0200
Auger Eric wrote:
> Hi Jacob,
>
> On 6/9/19 3:44 PM, Jacob Pan wrote:
> > When Shared Virtual Memory is exposed to a guest via vIOMMU,
> > scalable IOTLB invalidation may be passed down from outside IOMMU
> > subsystems. This patch adds invalidation functions t
The pull request you sent on Wed, 14 Aug 2019 16:12:17 +0200:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.3-4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e83b009c5c366b678c7986fa6c1d38fed06c954c
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Wed, 14 Aug 2019 16:09:09 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.3-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b5e33e44d994bb03c75f1901d47b1cf971f752a0
Thank you!
--
Deet-doot-
On Fri, Aug 09, 2019 at 06:07:41PM +0100, Robin Murphy wrote:
> To keep register-access quirks manageable, we want to structure things
> to avoid needing too many individual overrides. It seems fairly clean to
> have a single interface which handles both global and context registers
> in terms of t
With all the pieces in place, we can finally propagate the
iommu_iotlb_gather structure from the call to unmap() down to the IOMMU
drivers' implementation of ->tlb_add_page(). Currently everybody ignores
it, but the machinery is now there to defer invalidation.
Signed-off-by: Will Deacon
---
dri
In preparation for TLB flush gathering in the IOMMU API, rename the
iommu_gather_ops structure in io-pgtable to iommu_flush_ops, which
better describes its purpose and avoids the potential for confusion
between different levels of the API.
$ find linux/ -type f -name '*.[ch]' | xargs sed -i 's/gat
To allow IOMMU drivers to batch up TLB flushing operations and postpone
them until ->iotlb_sync() is called, extend the prototypes for the
->unmap() and ->iotlb_sync() IOMMU ops callbacks to take a pointer to
the current iommu_iotlb_gather structure.
All affected IOMMU drivers are updated, but the
The ->tlb_add_flush() callback in the io-pgtable API now looks a bit
silly:
- It takes a size and a granule, which are always the same
- It takes a 'bool leaf', which is always true
- It only ever flushes a single page
With that in mind, replace it with an optional ->tlb_add_page() callback
The ->tlb_sync() callback is no longer used, so it can be removed.
Signed-off-by: Will Deacon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 -
drivers/iommu/arm-smmu-v3.c | 8
drivers/iommu/arm-smmu.c| 17 +
drivers/iommu/io-pgtable-arm-v7
Hook up ->tlb_flush_walk() and ->tlb_flush_leaf() in drivers using the
io-pgtable API so that we can start making use of them in the page-table
code. For now, they can just wrap the implementations of ->tlb_add_flush
and ->tlb_sync pending future optimisation in each driver.
Signed-off-by: Will De
Introduce a helper function for drivers to use when updating an
iommu_iotlb_gather structure in response to an ->unmap() call, rather
than having to open-code the logic in every page-table implementation.
Signed-off-by: Will Deacon
---
include/linux/iommu.h | 31 +++
Commit b6b65ca20bc9 ("iommu/io-pgtable-arm: Add support for non-strict
mode") added an unconditional call to io_pgtable_tlb_sync() immediately
after the case where we replace a block entry with a table entry during
an unmap() call. This is redundant, since the IOMMU API will call
iommu_tlb_sync() o
In preparation for deferring TLB flushes to iommu_tlb_sync(), introduce
two new synchronous invalidation helpers to the io-pgtable API, which
allow the unmap() code to force invalidation in cases where it cannot be
deferred (e.g. when replacing a table with a block or when TLBI_ON_MAP
is set).
Sig
Update the io-pgtable ->unmap() function to take an iommu_iotlb_gather
pointer as an argument, and update the callers as appropriate.
Signed-off-by: Will Deacon
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
drivers/iommu/arm-smmu-v3.c | 2 +-
drivers/iommu/arm-smmu.c
Hi everybody,
These are the core IOMMU changes that I have posted previously as part
of my ongoing effort to reduce the lock contention of the SMMUv3 command
queue. I thought it would be better to split this out as a separate
series, since I think it's ready to go and all the driver conversions
me
To permit batching of TLB flushes across multiple calls to the IOMMU
driver's ->unmap() implementation, introduce a new structure for
tracking the address range to be flushed and the granularity at which
the flushing is required.
This is hooked into the IOMMU API and its caller are updated to make
Commit add02cfdc9bc ("iommu: Introduce Interface for IOMMU TLB Flushing")
added three new TLB flushing operations to the IOMMU API so that the
underlying driver operations can be batched when unmapping large regions
of IO virtual address space.
However, the ->iotlb_range_add() callback has not bee
Now that all IOMMU drivers using the io-pgtable API implement the
->tlb_flush_walk() and ->tlb_flush_leaf() callbacks, we can use them in
the io-pgtable code instead of ->tlb_add_flush() immediately followed by
->tlb_sync().
Signed-off-by: Will Deacon
---
drivers/iommu/io-pgtable-arm-v7s.c | 25
On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote:
> Hello
>
> Since lot of release (at least since 4.19), I hit the following error message:
> DMA-API: cacheline tracking ENOMEM, dma-debug disabled
>
> After hitting that, I try to check who is creating so many DMA mapping and
> see
On Wed, Aug 14, 2019 at 03:58:34PM +, Jason Gunthorpe wrote:
> On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote:
> > Looks good,
> >
> > Reviewed-by: Christoph Hellwig
>
> Dimitri, are you OK with this patch?
>
I think this looks OK.
Reviewed-by: Dimitri Sivanich
On 14/08/2019 18:20, Will Deacon wrote:
On Fri, Aug 09, 2019 at 06:07:38PM +0100, Robin Murphy wrote:
FIELD_PREP remains a terrible name, but the overall simplification will
make further work on this stuff that much more manageable. This also
serves as an audit of the header, wherein we can impo
On Fri, Aug 09, 2019 at 06:07:38PM +0100, Robin Murphy wrote:
> FIELD_PREP remains a terrible name, but the overall simplification will
> make further work on this stuff that much more manageable. This also
> serves as an audit of the header, wherein we can impose a consistent
> grouping and orderi
On Fri, 5 Jul 2019 10:21:27 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 6/28/19 4:22 AM, Jacob Pan wrote:
> >>> + }
> >>> + refcount_set(&svm->refs, 0);
> >>> + ioasid_set_data(data->hpasid, svm);
> >>> + INIT_LIST_HEAD_RCU(&svm->devs);
> >>> + INIT_LIST_HEAD
[ Upstream commit 3ee9eca760e7d0b68c55813243de66bbb499dc3b ]
There is a couple of places where on domain_init() failure domain_exit()
is called. While currently domain_init() can fail only if
alloc_pgtable_page() has failed.
Make domain_exit() check if domain->pgd present, before calling
domain_u
On Tue, Aug 06, 2019 at 08:15:45PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> radeon is using a device global hash table to track what mmu_notifiers
> have been registered on struct mm. This is better served with the new
> get/put scheme instead.
>
> radeon has a bug where it was
On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote:
> Looks good,
>
> Reviewed-by: Christoph Hellwig
Dimitri, are you OK with this patch?
Thanks,
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundatio
On 11/08/2019 09:05, Christoph Hellwig wrote:
We still treat devices without a DMA mask as defaulting to 32-bits for
both mask, but a few releases ago we've started warning about such
cases, as they require special cases to work around this sloppyness.
Add a dma_mask field to struct platform_obje
Hello
Since lot of release (at least since 4.19), I hit the following error message:
DMA-API: cacheline tracking ENOMEM, dma-debug disabled
After hitting that, I try to check who is creating so many DMA mapping and see:
cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c
6 a
Hi Yong Wu,
Sorry, but I'm still deeply confused by this patch.
On Sat, Aug 10, 2019 at 03:58:08PM +0800, 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_
The following changes since commit 451577f3e3a9bf1861218641dbbf98e214e77851:
Merge tag 'kbuild-fixes-v5.3-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
(2019-08-09 20:31:04 -0700)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-map
Hi Linus,
The following changes since commit e21a712a9685488f5ce80495b37b9fdbe96c230d:
Linux 5.3-rc3 (2019-08-04 18:40:12 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.3-rc4
for you to fetch changes up to 3a
This switches to using common code for the DMA allocations, including
potential use of the CMA allocator if configured.
Switching to the generic code enables DMA allocations from atomic
context, which is required by the DMA API documentation, and also
adds various other minor features drivers star
Stop providing our own arch alloc/free hooks for nommu platforms and
just expose the segment offset and use the generic dma-direct
allocator.
Signed-off-by: Christoph Hellwig
---
arch/microblaze/Kconfig | 2 +
arch/microblaze/mm/consistent.c | 93 +++--
2 fil
Hi Michal,
can you take a look at this patch that moves microblaze over to the
generic DMA remap allocator? I've been trying to slowly get all
architectures over to the generic code, and microblaze is one that
seems very straightfoward to convert.
___
i
This switches to using common code for the DMA allocations, including
potential use of the CMA allocator if configured.
Switching to the generic code enables DMA allocations from atomic
context, which is required by the DMA API documentation, and also
adds various other minor features drivers star
Hi Rich and Yoshinori,
can you take a quick look at this patch that moves sh over to the
generic DMA remap allocator? I've been trying to slowly get all
architectures over to the generic code, and I'd like merge this one
for 5.4 now that it has been posted a handful of times without any
feedback.
From: Joerg Roedel
This variable has no users anymore so it can be removed.
Signed-off-by: Joerg Roedel
---
arch/ia64/include/asm/iommu.h | 2 --
arch/ia64/kernel/pci-dma.c| 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/ia64/include/asm/iommu.h b/arch/ia64/include/asm/iommu.h
in
From: Joerg Roedel
Using Passthrough mode when SME is active causes certain
devices to use the SWIOTLB bounce buffer. The bounce buffer
code has an upper limit of 256kb for the size of DMA
allocations, which is too small for certain devices and
causes them to fail.
With this patch we enable IOMM
From: Joerg Roedel
This variable has no users anymore. Remove it and tell the
IOMMU code via its new functions about requested DMA modes.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/iommu.h | 1 -
arch/x86/kernel/pci-dma.c| 11 +++
2 files changed, 3 insertions(+), 9 dele
From: Joerg Roedel
Get rid of the iommu_pass_through variable and request
passthrough mode via the new iommu core function.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/io
Hi,
This patch-set started out small to overwrite the default passthrough
setting (through CONFIG_IOMMU_DEFAULT_PASSTHROUGH=y) when SME is active.
But on the way to that Tom reminded me that the current ways to
configure passthrough/no-passthrough modes for IOMMU on x86 is a mess.
So I added a fe
From: Joerg Roedel
Get rid of the iommu_pass_through variable and request
passthrough mode via the new iommu core function.
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iomm
From: Joerg Roedel
This kernel parameter now takes also effect on X86.
Signed-off-by: Joerg Roedel
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guid
From: Joerg Roedel
Set the default domain-type at runtime, not at compile-time.
This keeps default domain type setting in one place when we
have to change it at runtime.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 23 +++
1 file changed, 15 insertions(+), 8 dele
From: Joerg Roedel
Introduce an extensible concept to remember when certain
configuration settings for the IOMMU code have been set on
the kernel command line.
This will be used later to prevent overwriting these
settings with other defaults.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iomm
From: Joerg Roedel
Introduce a subsys_initcall for IOMMU code and use it to
print the default domain type at boot.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/dr
From: Joerg Roedel
Add a couple of functions to allow changing the default
domain type from architecture code and a function for iommu
drivers to request whether the default domain is
passthrough.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 16
include/linux/iommu.
Hi,
I've been struggling with the memory ordering requirements here. More below.
On Thu, Aug 01, 2019 at 08:20:40PM +0800, Zhen Lei wrote:
> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a
> smmu domain does not contain any ats master, the operations of
> arm_smmu_atc_in
On Tue, Aug 13, 2019 at 11:58:48AM +0800, Kai-Heng Feng wrote:
> at 23:39, Joerg Roedel wrote:
>
> > On Thu, Aug 08, 2019 at 06:17:07PM +0800, Kai-Heng Feng wrote:
> > > Raven Ridge systems may have malfunction touchpad or hang at boot if
> > > incorrect IVRS IOAPIC is provided by BIOS.
> > >
>
On Mon, Aug 12, 2019 at 12:32:46PM +0200, Marek Szyprowski wrote:
> Exynos SYSMMU driver supports deferred probe. It happens when clocks
> needed for this driver are not yet available. Typically next calls to
> driver ->probe() happen before init section is free, but this is not
> really guaranteed
Hi Lu Baolu,
On Tue, Jul 30, 2019 at 12:52:26PM +0800, Lu Baolu wrote:
> * iommu_bounce_map(dev, addr, paddr, size, dir, attrs)
> - Map a buffer start at DMA address @addr in bounce page
> manner. For buffer parts that doesn't cross a whole
> minimal IOMMU page, the bounce page policy is
On Wed, Aug 14, 2019 at 10:18:25AM +0200, Joerg Roedel wrote:
> On Sat, Aug 10, 2019 at 03:58:00PM +0800, Yong Wu wrote:
> > Change notes:
> > v9:
> >1) rebase on v5.3-rc1.
> >2) In v7s, Use oas to implement MTK 4GB mode. It nearly reconstruct the
> > patch, so I don't keep the R-b.
>
On Sat, Aug 10, 2019 at 03:58:00PM +0800, Yong Wu wrote:
> Change notes:
> v9:
>1) rebase on v5.3-rc1.
>2) In v7s, Use oas to implement MTK 4GB mode. It nearly reconstruct the
> patch, so I don't keep the R-b.
Okay, this looks close to being ready, just the io-pgtable patches still
n
70 matches
Mail list logo
