On Thu, Dec 06, 2018 at 11:55:02AM +0800, Nicolas Boichat wrote:
>On Thu, Dec 6, 2018 at 11:32 AM Wei Yang wrote:
>>
>> On Thu, Dec 06, 2018 at 08:41:36AM +0800, Nicolas Boichat wrote:
>> >On Wed, Dec 5, 2018 at 8:18 PM Wei Yang wrote:
>> >>
>> >> On Wed, Dec 05, 2018 at 03:39:51PM +0800,
Fix the comment as swiotlb_bounce() is used to copy from original dma
location to swiotlb buffer during swiotlb_tbl_map_single(), while to
copy from swiotlb buffer to original dma location during
swiotlb_tbl_unmap_single().
Signed-off-by: Dongli Zhang
---
kernel/dma/swiotlb.c | 2 +-
1 file
The device driver will not be able to do dma operations once swiotlb buffer
is full, either because the driver is using so many IO TLB blocks inflight,
or because there is memory leak issue in device driver. To export the
swiotlb buffer usage via debugfs would help the user estimate the size of
On Thu, Dec 6, 2018 at 11:32 AM Wei Yang wrote:
>
> On Thu, Dec 06, 2018 at 08:41:36AM +0800, Nicolas Boichat wrote:
> >On Wed, Dec 5, 2018 at 8:18 PM Wei Yang wrote:
> >>
> >> On Wed, Dec 05, 2018 at 03:39:51PM +0800, Nicolas Boichat wrote:
> >> >On Wed, Dec 5, 2018 at 3:25 PM Wei Yang wrote:
On Wed, Dec 5, 2018 at 10:02 PM Vlastimil Babka wrote:
>
> On 12/5/18 6:48 AM, 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
On Thu, Dec 06, 2018 at 08:41:36AM +0800, Nicolas Boichat wrote:
>On Wed, Dec 5, 2018 at 8:18 PM Wei Yang wrote:
>>
>> On Wed, Dec 05, 2018 at 03:39:51PM +0800, Nicolas Boichat wrote:
>> >On Wed, Dec 5, 2018 at 3:25 PM Wei Yang wrote:
>> >>
>> >> On Wed, Dec 05, 2018 at 01:48:27PM +0800, Nicolas
Hi Joerg,
On 12/5/18 11:56 PM, Joerg Roedel wrote:
On Tue, Dec 04, 2018 at 02:13:31PM +0800, Lu Baolu wrote:
The existing code uses GFP_ATOMIC, this patch only changes the size of
the allocated desc_page.
I don't think we really need GFP_ATOMIC here (and also for some other
places). I will
Hi Joerg,
On 12/5/18 11:50 PM, Joerg Roedel wrote:
On Tue, Dec 04, 2018 at 01:58:06PM +0800, Lu Baolu wrote:
This function is called in an unsleepable context.
spin_lock()
[...]
if (pasid_table_is_necessary)
allocate_pasid_table(dev)
[...]
spin_unlock()
We can move it out of the lock
On Wed, Dec 5, 2018 at 8:18 PM Wei Yang wrote:
>
> On Wed, Dec 05, 2018 at 03:39:51PM +0800, Nicolas Boichat wrote:
> >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),
With no callers left, we can clean up this part of dma-debug's exposed
internals, making way to tweak the allocation behaviour.
Signed-off-by: Robin Murphy
---
v2: New
include/linux/dma-debug.h | 7 ---
kernel/dma/debug.c| 30 --
2 files changed, 37
dma-debug is now capable of adding new entries to its pool on-demand if
the initial preallocation was insufficient, so the IOMMU_LEAK logic no
longer needs to explicitly change the pool size. This does lose it the
ability to save a couple of megabytes of RAM by reducing the pool size
below its
Make the prealloc_memory() logic 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() a bit.
Signed-off-by: Robin Murphy
---
v2: Give it a better name, simplify the locking mess
DMA debug entries are one of those things which aren't that useful
individually - we will always want some larger quantity of them - and
that we don't really need to manage the exact number of - we only care
about having 'enough'. In that regard, the current behaviour of creating
them one-by-one
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 trigger the "DMA-API: debugging out of memory - disabling"
message
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 device can
cause DMA debug to disable itself during boot unless explicitly given an
appropriate
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 instead of somewhere in the middle.
Reviewed-by: Christoph Hellwig
Hi all,
Here's some assorted cleanup and improvements to dma-debug which grew
out of the problem that certain drivers use very large numbers of DMA
mappings, and knowing when to override "dma_debug_entries=..." and what
value to override it with can be a less-than-obvious task for users.
The
Expose nr_total_entries in debugfs, so that {num,min}_free_entries
become even more meaningful to users interested in current/maximum
utilisation. This becomes even more relevant once nr_total_entries
may change at runtime beyond just the existing AMD GART debug code.
Suggested-by: John Garry
On Wed, Dec 05, 2018 at 05:09:55PM +0100, Joerg Roedel wrote:
> On Tue, Dec 04, 2018 at 03:37:16PM -0700, Yu Zhao wrote:
> > 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
On 05/12/2018 14:36, Joerg Roedel wrote:
From: Joerg Roedel
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
On 05/12/2018 14:36, Joerg Roedel wrote:
From: Joerg Roedel
Put them into separate functions and call those where the
plain ops have been called before.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 54 ++-
include/linux/iommu.h | 3 +++
On 04/12/2018 16:29, Joerg Roedel wrote:
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
---
On 04/12/2018 16:30, Joerg Roedel wrote:
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 +--
Hey,
There exists an issue in the logic used to determine domain association
with devices. Currently the driver uses find_or_alloc_domain to either
reuse an existing domain or allocate a new one if one isn’t found. Domains
should be shared between all members of an IOMMU group as this is the
On 04/12/2018 17:25, Joerg Roedel wrote:
From: Joerg Roedel
Use Use device_iommu_mapped() to check if the device is
already mapped by an IOMMU.
FWIW, this check (and its ACPI equivalent in patch #3) is specifically
asking "has .add_device() already been called?", rather than the more
Hi Joerg,
On 04/12/2018 17:24, Joerg Roedel wrote:
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
On Tue, Dec 04, 2018 at 03:37:16PM -0700, Yu Zhao wrote:
> 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
On Tue, Dec 04, 2018 at 06:27:34PM +, Tom Murphy wrote:
> 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(-)
Applied, thanks.
On Tue, Dec 04, 2018 at 02:13:31PM +0800, Lu Baolu wrote:
> The existing code uses GFP_ATOMIC, this patch only changes the size of
> the allocated desc_page.
>
> I don't think we really need GFP_ATOMIC here (and also for some other
> places). I will clean up them in a separated patch.
Okay,
On Tue, Dec 04, 2018 at 01:58:06PM +0800, Lu Baolu wrote:
> This function is called in an unsleepable context.
>
> spin_lock()
> [...]
> if (pasid_table_is_necessary)
> allocate_pasid_table(dev)
> [...]
> spin_unlock()
>
> We can move it out of the lock range.
>
> How about
>
> if
On Mon, Dec 03, 2018 at 05:23:40PM +, Liu, Yi L wrote:
> So for a device without PASID support, we need to at least to have a PASID
> entry so that its DMA request (without pasid) can be translated. Thus a PASID
> table is needed for such devices.
That makes sense, thanks for the explanation.
On Wed, Dec 05, 2018 at 06:54:18AM -0800, Christoph Hellwig wrote:
> > +void iommu_release_device(struct device *dev)
>
> Nitpick: there seems to be a double space here.
>
> > +int iommu_probe_device(struct device *dev);
> > +void iommu_release_device(struct device *dev);
>
> .. and here.
> +void iommu_release_device(struct device *dev)
Nitpick: there seems to be a double space here.
> +int iommu_probe_device(struct device *dev);
> +void iommu_release_device(struct device *dev);
.. and here.
___
iommu mailing list
On 12/5/18 6:48 AM, 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 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> is defined (e.g. on arm64
On Wed, Dec 05, 2018 at 06:43:08AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 05, 2018 at 02:40:06PM +, Robin Murphy wrote:
> > 32-bit Arm doesn't have ZONE_DMA32, but has (or at least had at the time) a
> > 2GB ZONE_DMA. Whether we actually need that or not depends on how this all
> >
On Wed, Dec 05, 2018 at 02:40:06PM +, Robin Murphy wrote:
> 32-bit Arm doesn't have ZONE_DMA32, but has (or at least had at the time) a
> 2GB ZONE_DMA. Whether we actually need that or not depends on how this all
> interacts with LPAE and highmem, but I'm not sure of those details off-hand.
On Wed, Dec 05, 2018 at 10:04:00AM +0800, 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
On 05/12/2018 13:54, Christoph Hellwig wrote:
On Wed, Dec 05, 2018 at 01:48:28PM +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.
+#ifdef CONFIG_ZONE_DMA32
From: Joerg Roedel
Remove the iommu_ prefix from the function and a few other
static data structures so that the iommu_release_device name
can be re-used in iommu core code.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu-sysfs.c | 12 ++--
1 file changed, 6 insertions(+), 6
From: Joerg Roedel
Put them into separate functions and call those where the
plain ops have been called before.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 54 ++-
include/linux/iommu.h | 3 +++
2 files changed, 31 insertions(+), 26
Hi,
this patch-set consolidates the calls to iommu_ops->add_device()
and remove_device() and the necessary checks into
probe/release functions that be extended later with more
setup work.
Regards,
Joerg
Joerg Roedel (4):
iommu/sysfs: Rename iommu_release_device()
iommu: Consolitate
From: Joerg Roedel
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index
From: Joerg Roedel
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm64/iort.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index
On Wed, Dec 05, 2018 at 10:44:05AM +0100, Christian Zigotzky wrote:
> Thanks for your reply. I undid all dma mapping commits with the following
> command:
>
> git checkout 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97
>
> After that I compiled the kernels with this code for my P5020 board (Cyrus)
>
On 12/5/18 6:48 AM, 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 allocate memory
On Wed, Dec 05, 2018 at 01:48:28PM +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.
> +#ifdef CONFIG_ZONE_DMA32
> +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA32
>
Thanks, applied.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 12/5/18 6:48 AM, Nicolas Boichat wrote:
> 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")
Well, not really. Patch 3 does that and yeah this will
On Wed, Dec 05, 2018 at 11:14:01AM +0100, Marek Szyprowski wrote:
> Commit bfd56cd60521 ("dma-mapping: support highmem in the generic remap
> allocator") replaced dma_direct_alloc_pages() with __dma_direct_alloc_pages(),
> which doesn't set dma_handle and zero allocated memory. Fix it by doing
On Wed, Dec 05, 2018 at 03:39:51PM +0800, Nicolas Boichat wrote:
>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
On Wed, 2018-12-05 at 17:01 +0530, Anshuman Khandual wrote:
>
> On 12/05/2018 02:56 AM, Lubomir Rintel wrote:
> > 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
On Wed 05-12-18 19:01:03, Nicolas Boichat wrote:
[...]
> > Secondly, why do we need a new sysfs file? Who is going to consume it?
>
> We have cache_dma, so it seems consistent to add cache_dma32.
I wouldn't copy a pattern unless there is an explicit usecase for it.
We do expose way too much to
On 12/05/2018 02:56 AM, Lubomir Rintel wrote:
> 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
On 12/05/2018 10:30 AM, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 19717e78a04d51512cf0e7b9b09c61f06b2af071 ("[PATCH V2] mm: Replace all
> open encodings for NUMA_NO_NODE")
> url:
>
On Wed, Dec 5, 2018 at 5:56 PM Michal Hocko wrote:
>
> On Wed 05-12-18 13:48:27, 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
Commit bfd56cd60521 ("dma-mapping: support highmem in the generic remap
allocator") replaced dma_direct_alloc_pages() with __dma_direct_alloc_pages(),
which doesn't set dma_handle and zero allocated memory. Fix it by doing this
directly in the caller function.
Fixes: bfd56cd60521 ("dma-mapping:
On Wed 05-12-18 13:48:27, 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 allocate
On 04 December 2018 at 3:24PM, Christoph Hellwig wrote:
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.
Em Fri, 14 Sep 2018 14:19:29 +0200
Marek Szyprowski escreveu:
> Hi Robin,
>
> On 2018-09-12 18:45, Robin Murphy wrote:
> > Having of_reserved_mem_device_init() forcibly reconfigure DMA for all
> > callers, potentially overriding the work done by a bus-specific
> > .dma_configure method earlier,
On Wed, Dec 05, 2018 at 03:39:51PM +0800, Nicolas Boichat wrote:
>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
On Thu, Nov 29, 2018 at 06:51:49PM +0300, Mika Westerberg wrote:
> Recent systems with Thunderbolt ports may be utilizing IOMMU to prevent DMA
> attacks. This is different from the previous security level based scheme
> because the connected device cannot access system memory outside of the
>
61 matches
Mail list logo
