On Wed, Dec 5, 2018 at 3:25 PM Wei Yang wrote:
>
> On Wed, Dec 05, 2018 at 01:48:27PM +0800, Nicolas Boichat wrote:
> >In some cases (e.g. IOMMU ARMv7s page allocator), we need to allocate
> >data structures smaller than a page with GFP_DMA32 flag.
> >
> >This change makes it possible to create a
On Wed, Dec 05, 2018 at 01:48:27PM +0800, Nicolas Boichat wrote:
>In some cases (e.g. IOMMU ARMv7s page allocator), we need to allocate
>data structures smaller than a page with GFP_DMA32 flag.
>
>This change makes it possible to create a custom cache in DMA32 zone
>using kmem_cache_create, then
On Wed, Dec 5, 2018 at 10:04 AM Nicolas Boichat wrote:
>
> On Tue, Dec 4, 2018 at 10:35 PM Vlastimil Babka wrote:
> >
> > On 12/4/18 10:37 AM, Nicolas Boichat wrote:
> > > On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat
> > > wrote:
> > >>
> > >> This is a follow-up to the discussion in [1],
IOMMUs using ARMv7 short-descriptor format require page tables
(level 1 and 2) to be allocated within the first 4GB of RAM, even
on 64-bit systems.
For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
is defined (e.g. on arm64 platforms).
For level 2 pages, allocate a slab cache in
Remove duplicated code between slab and slub, and will make it
easier to make the test more complicated in the next commits.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
mm/internal.h | 18 --
mm/slab.c | 8 +---
In some cases (e.g. IOMMU ARMv7s page allocator), we need to allocate
data structures smaller than a page with GFP_DMA32 flag.
This change makes it possible to create a custom cache in DMA32 zone
using kmem_cache_create, then allocate memory using kmem_cache_alloc.
We do not create a DMA32
This is a follow-up to the discussion in [1], [2].
IOMMUs using ARMv7 short-descriptor format require page tables
(level 1 and 2) to be allocated within the first 4GB of RAM, even
on 64-bit systems.
For L1 tables that are bigger than a page, we can just use __get_free_pages
with GFP_DMA32 (on
On Mon, 2018-12-03 at 17:28 +, Robin Murphy wrote:
> Use pr_fmt() to generate the "DMA-API: " prefix consistently. This
> results in it being added to a couple of pr_*() messages which were
> missing it before, and for the err_printk() calls moves it to the actual
> start of the message
On Tue, Dec 4, 2018 at 10:35 PM Vlastimil Babka wrote:
>
> On 12/4/18 10:37 AM, Nicolas Boichat wrote:
> > On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat
> > wrote:
> >>
> >> This is a follow-up to the discussion in [1], to make sure that the page
> >> tables allocated by
The parameter is still there but it's ignored. We need to check its
value before deciding to go into passthrough mode for AMD IOMMU.
Fixes: aafd8ba0ca74 ("iommu/amd: Implement add_device and remove_device")
Signed-off-by: Yu Zhao
---
drivers/iommu/amd_iommu.c | 3 ++-
1 file changed, 2
On Tue, Dec 04, 2018 at 04:41:34PM +, Robin Murphy wrote:
> I'd have been inclined to put the default check here, i.e.
>
> - return 0
> + return dma_addr == DMA_MAPPING_ERROR
>
> such that the callback retains full precedence and we don't have to deal
> with the non-trivial removals
On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
>
> This solves a problem we see with drm/msm, caused by getting
> iommu_dma_ops while we attach our own domain and manage it directly at
> the iommu API level:
>
> [0038] user address but active_mm is swapper
> Internal error:
On Tue, Dec 4, 2018 at 11:26 PM Tony Battersby wrote:
>
> On 12/4/18 3:30 PM, Andy Shevchenko wrote:
> > On Tue, Dec 4, 2018 at 10:18 PM Matthew Wilcox wrote:
> >> On Tue, Dec 04, 2018 at 12:14:43PM -0800, Andrew Morton wrote:
> >>> Also, Andy had issues with the v2 series so it would be good to
On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace these open encodings for an invalid node number with the
>
On 12/4/18 3:30 PM, Andy Shevchenko wrote:
> On Tue, Dec 4, 2018 at 10:18 PM Matthew Wilcox wrote:
>> On Tue, Dec 04, 2018 at 12:14:43PM -0800, Andrew Morton wrote:
>>> Also, Andy had issues with the v2 series so it would be good to hear an
>>> update from him?
>> Certainly.
> Hmm... I certainly
On Tue, Dec 04, 2018 at 12:28:54PM -0800, Andrew Morton wrote:
> On Tue, 4 Dec 2018 12:18:01 -0800 Matthew Wilcox wrote:
> > I only had a review comment on 8/9, which I then withdrew during my review
> > of patch 9/9. Unless I missed something during my re-review of my
> > responses?
>
> And
On Tue, Dec 4, 2018 at 10:18 PM Matthew Wilcox wrote:
> On Tue, Dec 04, 2018 at 12:14:43PM -0800, Andrew Morton wrote:
> > Also, Andy had issues with the v2 series so it would be good to hear an
> > update from him?
>
> Certainly.
Hmm... I certainly forgot what was long time ago.
If I _was_ in
On Tue, 4 Dec 2018 12:18:01 -0800 Matthew Wilcox wrote:
> On Tue, Dec 04, 2018 at 12:14:43PM -0800, Andrew Morton wrote:
> > On Tue, 4 Dec 2018 11:22:34 -0500 Tony Battersby
> > wrote:
> >
> > > On 11/13/18 1:36 AM, Matthew Wilcox wrote:
> > > > On Mon, Nov 12, 2018 at 10:46:35AM -0500, Tony
On Tue, Dec 04, 2018 at 12:14:43PM -0800, Andrew Morton wrote:
> On Tue, 4 Dec 2018 11:22:34 -0500 Tony Battersby
> wrote:
>
> > On 11/13/18 1:36 AM, Matthew Wilcox wrote:
> > > On Mon, Nov 12, 2018 at 10:46:35AM -0500, Tony Battersby wrote:
> > >> Prevent a possible endless loop with
On Tue, 4 Dec 2018 11:22:34 -0500 Tony Battersby wrote:
> On 11/13/18 1:36 AM, Matthew Wilcox wrote:
> > On Mon, Nov 12, 2018 at 10:46:35AM -0500, Tony Battersby wrote:
> >> Prevent a possible endless loop with DMAPOOL_DEBUG enabled if a buggy
> >> driver corrupts DMA pool memory.
> >>
> >>
From: tom
Someone forgot to update this comment.
Signed-off-by: Tom Murphy
---
include/linux/iommu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a1d28f42cb77..11db18b9ffe8 100644
--- a/include/linux/iommu.h
+++
In fact, having got this far in, what I'd quite like to do is to get rid
of dma_debug_resize_entries() such that we never need to free things at
all, since then we could allocate whole pages as blocks of entries to
save on masses of individual slab allocations.
On a related topic, is it
From: Joerg Roedel
Replace the dev->iommu_group check with a proper function
call that better reprensents its purpose.
Cc: Mathias Nyman
Signed-off-by: Joerg Roedel
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c
From: Joerg Roedel
Use the new function to replace the open-coded iommu check.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Russell Currey
Cc: Sam Bobroff
Signed-off-by: Joerg Roedel
---
arch/powerpc/kernel/eeh.c | 2 +-
arch/powerpc/kernel/iommu.c | 6 +++---
2 files changed, 4
From: Joerg Roedel
Use Use device_iommu_mapped() to check if the device is
already mapped by an IOMMU.
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index
From: Joerg Roedel
Replace the iommu-check with a proper and readable function
call.
Cc: Lorenzo Pieralisi
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm64/iort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index
From: Joerg Roedel
Some places in the kernel check the iommu_group pointer in
'struct device' in order to find ot whether a device is
mapped by an IOMMU.
This is not good way to make this check, as the pointer will
be moved to 'struct dev_iommu_data'. This way to make the
check is also not very
Hi,
here is a patch-set to replace the dev->iommu_group checks
in the source tree by a proper function call. The pointer
checks mostly happen to check whether a device is managed my
an IOMMU. For that purpose a pointer check is not very
descriptable, so replace it by a function call that make its
On 04/12/2018 16:30, John Garry wrote:
On 04/12/2018 13:11, Robin Murphy wrote:
Hi John,
On 03/12/2018 18:23, John Garry wrote:
On 03/12/2018 17:28, Robin Murphy wrote:
Certain drivers such as large multi-queue network adapters can use
pools
of mapped DMA buffers larger than the default
On 30/11/2018 13:22, Christoph Hellwig wrote:
Error handling of the dma_map_single and dma_map_page APIs is a little
problematic at the moment, in that we use different encodings in the
returned dma_addr_t to indicate an error. That means we require an
additional indirect call to figure out if
On Tue, Dec 04, 2018 at 04:23:00PM +0800, Nicolas Boichat wrote:
> IOMMUs using ARMv7 short-descriptor format require page tables
> (level 1 and 2) to be allocated within the first 4GB of RAM, even
> on 64-bit systems.
>
> For level 1/2 tables, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> is
On 04/12/2018 14:29, Christoph Hellwig wrote:
+ for (retry_count = 0; ; retry_count++) {
+ spin_lock_irqsave(_entries_lock, flags);
+
+ if (num_free_entries > 0)
+ break;
spin_unlock_irqrestore(_entries_lock, flags);
Taking a
On 04/12/2018 13:11, Robin Murphy wrote:
Hi John,
On 03/12/2018 18:23, John Garry wrote:
On 03/12/2018 17:28, Robin Murphy wrote:
Certain drivers such as large multi-queue network adapters can use pools
of mapped DMA buffers larger than the default dma_debug_entry pool of
65536 entries, with
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Thierry Reding
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-smmu.c | 2 +-
1 file changed, 1
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 7 +--
1 file changed, 5 insertions(+), 2
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Lorenzo Pieralisi
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm64/iort.c | 12 +++-
1 file changed,
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Rob Clark
Signed-off-by: Joerg Roedel
---
drivers/iommu/qcom_iommu.c | 18 ++
1 file changed,
Hi,
here is a patch-set to wrap accesses to dev->iommu_fwspec
into functions. This will make it easier to move the pointer
into a separate struct and consolitdate the iommu-related
pointers in 'struct device'.
Regards,
Joerg
Joerg Roedel (9):
iommu: Introduce wrappers around
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Signed-off-by: Joerg Roedel
---
drivers/iommu/ipmmu-vmsa.c | 12
1 file changed, 8 insertions(+), 4
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Matthias Brugger
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.c| 21 -
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Will Deacon
Cc: Robin Murphy
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu-v3.c | 16
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Signed-off-by: Joerg Roedel
---
drivers/iommu/dma-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Joerg Roedel
These wrappers will be used to easily change the location of
the field later when all users are converted.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 14 +++---
include/linux/iommu.h | 11 +++
2 files changed, 18 insertions(+), 7 deletions(-)
On Tue, Dec 04, 2018 at 05:37:13PM +0800, Nicolas Boichat wrote:
> On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat wrote:
> >
> > This is a follow-up to the discussion in [1], to make sure that the page
> > tables allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit
> > physical
On 11/13/18 1:36 AM, Matthew Wilcox wrote:
> On Mon, Nov 12, 2018 at 10:46:35AM -0500, Tony Battersby wrote:
>> Prevent a possible endless loop with DMAPOOL_DEBUG enabled if a buggy
>> driver corrupts DMA pool memory.
>>
>> Signed-off-by: Tony Battersby
> I like it! Also, here you're using
Hi Konrad and others,
can you review this series? It merges the swiotlb support into the
DMA direct ops so that we don't have to duplicate the dma mapping logic
in multiple places.
Note that this is based on the dma_mapping_error series for which I'd
still like to collect a few more reviews, so
We can use DMA_MAPPING_ERROR instead, which already maps to the same
value.
Signed-off-by: Christoph Hellwig
---
drivers/xen/swiotlb-xen.c | 4 ++--
include/linux/swiotlb.h | 3 ---
kernel/dma/swiotlb.c | 4 ++--
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git
While the dma-direct code is (relatively) clean and simple we actually
have to use the swiotlb ops for the mapping on many architectures due
to devices with addressing limits. Instead of keeping two
implementations around this commit allows the dma-direct
implementation to call the swiotlb bounce
No need to duplicate the mapping logic.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index edb24f94ea1e..d45306473c90 100644
--- a/kernel/dma/direct.c
+++
Only report report a DMA addressability report once to avoid spewing the
kernel log with repeated message. Also provide a stack trace to make it
easy to find the actual caller that caused the problem.
Last but not least move the actual check into the fast path and only
leave the error reporting
Instead of providing a special dma_mark_clean hook just for ia64, switch
ia64 to use the normal arch_sync_dma_for_cpu hooks instead.
This means that we now also set the PG_arch_1 bit for pages in the
swiotlb buffer, which isn't stricly needed as we will never execute code
out of the swiotlb
On 04/12/2018 14:27, Christoph Hellwig wrote:
On Mon, Dec 03, 2018 at 05:28:07PM +, Robin Murphy wrote:
Make prealloc_memory() a little more general and robust so that it
serves for runtime reallocations too. The first thing we can do with
that is clean up dma_debug_resize_entries() quite a
On 04/12/2018 14:17, Christoph Hellwig wrote:
On Tue, Dec 04, 2018 at 01:11:37PM +, Robin Murphy wrote:
In fact, having got this far in, what I'd quite like to do is to get rid of
dma_debug_resize_entries() such that we never need to free things at all,
since then we could allocate whole
We already zero the memory after allocating it from the pool that
this function fills, and having the memset here in this form means
we can't support CMA highmem allocations.
Signed-off-by: Christoph Hellwig
Reported-by: Russell King - ARM Linux
---
kernel/dma/remap.c | 1 -
1 file changed, 1
We can just call the regular calls after adding offset the the address instead
of reimplementing them.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-debug.h | 27
include/linux/dma-mapping.h | 34 +-
kernel/dma/debug.c |
On 04/12/2018 11:01, Vivek Gautam wrote:
Qualcomm SoCs have an additional level of cache called as
System cache, aka. Last level cache (LLC). This cache sits right
before the DDR, and is tightly coupled with the memory controller.
The cache is available to all the clients present in the SoC
On 12/4/18 10:37 AM, Nicolas Boichat wrote:
> On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat wrote:
>>
>> This is a follow-up to the discussion in [1], to make sure that the page
>> tables allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit
>> physical address space.
>>
>> [1]
>>
On Mon, Dec 03, 2018 at 05:28:09PM +, Robin Murphy wrote:
> Now that we can dynamically allocate DMA debug entries to cope with
> drivers maintaining excessively large numbers of live mappings, a driver
> which *does* actually have a bug leaking mappings (and is not unloaded)
> will no longer
> + for (retry_count = 0; ; retry_count++) {
> + spin_lock_irqsave(_entries_lock, flags);
> +
> + if (num_free_entries > 0)
> + break;
>
> spin_unlock_irqrestore(_entries_lock, flags);
Taking a spinlock just to read a single integer
On Mon, Dec 03, 2018 at 05:28:07PM +, Robin Murphy wrote:
> Make prealloc_memory() a little more general and robust so that it
> serves for runtime reallocations too. The first thing we can do with
> that is clean up dma_debug_resize_entries() quite a bit.
Maybe also renamed it to
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Dec 04, 2018 at 04:23:00PM +0800, Nicolas Boichat wrote:
> IOMMUs using ARMv7 short-descriptor format require page tables
> (level 1 and 2) to be allocated within the first 4GB of RAM, even
> on 64-bit systems.
>
> For level 1/2 tables, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> is
On Tue, Dec 04, 2018 at 10:53:39AM +0100, Christian Zigotzky wrote:
> I don't know why this kernel doesn't recognize the hard disks connected to
> my physical P5020 board and why the onboard ethernet on my PASEMI board
> doesn't work. (dma_direct_map_page: overflow)
Do you know if this actually
On Tue, Dec 04, 2018 at 09:38:02AM +0100, Marek Szyprowski wrote:
> Hi All,
>
> On 2018-11-30 20:05, Robin Murphy wrote:
> > On 05/11/2018 12:19, Christoph Hellwig wrote:
> >> By using __dma_direct_alloc_pages we can deal entirely with struct page
> >> instead of having to derive a kernel virtual
> > +int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
> > +{
> > + unsigned int pool_size_order = get_order(atomic_pool_size);
> > + unsigned long nr_pages = atomic_pool_size >> PAGE_SHIFT;
> > + struct page *page;
> > + void *addr;
> > + int ret;
> > +
> > + if
On Tue, Dec 04, 2018 at 01:11:37PM +, Robin Murphy wrote:
> In fact, having got this far in, what I'd quite like to do is to get rid of
> dma_debug_resize_entries() such that we never need to free things at all,
> since then we could allocate whole pages as blocks of entries to save on
>
From: Qian Cai
> Sent: 30 November 2018 21:48
> To: h...@lst.de; m.szyprow...@samsung.com; robin.mur...@arm.com
> Cc: yisen.zhu...@huawei.com; salil.me...@huawei.com; john.ga...@huawei.com;
> linux...@huawei.com;
> iommu@lists.linux-foundation.org; net...@vger.kernel.org;
>
Hi John,
On 03/12/2018 18:23, John Garry wrote:
On 03/12/2018 17:28, Robin Murphy wrote:
Certain drivers such as large multi-queue network adapters can use pools
of mapped DMA buffers larger than the default dma_debug_entry pool of
65536 entries, with the result that merely probing such a
Qualcomm SoCs have an additional level of cache called as
System cache, aka. Last level cache (LLC). This cache sits right
before the DDR, and is tightly coupled with the memory controller.
The cache is available to all the clients present in the SoC system.
The clients request their slices from
On Mon, Nov 05, 2018 at 01:19:26PM +0100, Christoph Hellwig wrote:
> The arm64 codebase to implement coherent dma allocation for architectures
> with non-coherent DMA is a good start for a generic implementation, given
> that is uses the generic remap helpers, provides the atomic pool for
>
On 04 December 2018 at 08:31AM, Christian Zigotzky wrote:
Hi All,
Could you please test Christoph's kernel on your PASEMI and NXP
boards? Download:
'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'
Thanks,
Christian
I successfully tested this kernel on a virtual
On Sun, Nov 11, 2018 at 5:04 PM Nicolas Boichat wrote:
>
> This is a follow-up to the discussion in [1], to make sure that the page
> tables allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit
> physical address space.
>
> [1]
>
On Mon, Dec 03, 2018 at 06:28:00PM -0600, Bjorn Helgaas wrote:
> On Thu, Nov 29, 2018 at 06:51:50PM +0300, Mika Westerberg wrote:
> > A malicious PCI device may use DMA to attack the system. An external
> > Thunderbolt port is a convenient point to attach such a device. The OS
> > may use IOMMU to
Hi All,
On 2018-11-30 20:05, Robin Murphy wrote:
> On 05/11/2018 12:19, Christoph Hellwig wrote:
>> By using __dma_direct_alloc_pages we can deal entirely with struct page
>> instead of having to derive a kernel virtual address.
>
> Simple enough :)
>
> Reviewed-by: Robin Murphy
This patch has
IOMMUs using ARMv7 short-descriptor format require page tables
(level 1 and 2) to be allocated within the first 4GB of RAM, even
on 64-bit systems.
For level 1/2 tables, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
is defined (e.g. on arm64 platforms).
For level 2 tables (1 KB), we use
75 matches
Mail list logo
