Good to know. Sorry because of the email.
Sent from my iPhone
> On 6. Dec 2018, at 20:36, Christoph Hellwig wrote:
>
>> On Thu, Dec 06, 2018 at 06:10:54PM +0100, Christian Zigotzky wrote:
>> Please don’t merge this code. We are still testing and trying to figure out
>> where the problems are
On 12/7/18 7:16 AM, Nicolas Boichat wrote:
> IOMMUs using ARMv7 short-descriptor format require page tables
> to be allocated within the first 4GB of RAM, even on 64-bit systems.
> On arm64, this is done by passing GFP_DMA32 flag to memory allocation
> functions.
>
> For IOMMU L2 tables that only
On 12/6/18 9:49 PM, Dongli Zhang wrote:
>
>
> On 12/07/2018 12:12 AM, Joe Jin wrote:
>> Hi Dongli,
>>
>> Maybe move d_swiotlb_usage declare into swiotlb_create_debugfs():
>
> I assume the call of swiotlb_tbl_map_single() might be frequent in some
> situations, e.g., when 'swiotlb=force'.
>
>
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
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
IOMMUs using ARMv7 short-descriptor format require page tables
to be allocated within the first 4GB of RAM, even on 64-bit systems.
On arm64, this is done by passing GFP_DMA32 flag to memory allocation
functions.
For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
a full page
A previous patch in this series adds support for SLAB_CACHE_DMA32
kmem caches. This adds the corresponding
/sys/kernel/slab/cache/cache_dma32 entries, and fixes slabinfo
tool.
Signed-off-by: Nicolas Boichat
---
There were different opinions on whether this sysfs entry should
be added, so I'll
On 12/07/2018 12:12 AM, Joe Jin wrote:
> Hi Dongli,
>
> Maybe move d_swiotlb_usage declare into swiotlb_create_debugfs():
I assume the call of swiotlb_tbl_map_single() might be frequent in some
situations, e.g., when 'swiotlb=force'.
That's why I declare the d_swiotlb_usage out of any
On Thu, Dec 06, 2018 at 08:24:38PM +, Robin Murphy wrote:
> On 06/12/2018 20:00, Christoph Hellwig wrote:
>> On Thu, Dec 06, 2018 at 06:54:17PM +, Robin Murphy wrote:
>>> I'm pretty sure we used to assign dummy_dma_ops explicitly to devices at
>>> the point we detected the ACPI properties
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 v2
capable device.
We occasionally use this parameter to force v2 capable device into
translation mode to debug memory corruption that we suspect is
caused by DMA
On 06/12/2018 20:00, Christoph Hellwig wrote:
On Thu, Dec 06, 2018 at 06:54:17PM +, Robin Murphy wrote:
I'm pretty sure we used to assign dummy_dma_ops explicitly to devices at
the point we detected the ACPI properties are wrong - that shouldn't be too
much of a headache to go back to.
On Thu, Dec 06, 2018 at 06:54:17PM +, Robin Murphy wrote:
> I'm pretty sure we used to assign dummy_dma_ops explicitly to devices at
> the point we detected the ACPI properties are wrong - that shouldn't be too
> much of a headache to go back to.
Ok. I've cooked up a patch to use NULL as
On Thu, Dec 06, 2018 at 06:10:54PM +0100, Christian Zigotzky wrote:
> Please don’t merge this code. We are still testing and trying to figure out
> where the problems are in the code.
The ones I sent pings for were either tested successfully by you
(the zone change) or are trivial cleanups that
On 06/12/2018 18:43, Christoph Hellwig wrote:
On Thu, Dec 06, 2018 at 10:28:22AM -0800, Linus Torvalds wrote:
which is counterproductive because it checks for the fast case *after*
you've done a load (and a check) that is entirely pointless for the
fast case.
Put another way, you made the fast
On Thu, Dec 6, 2018 at 10:43 AM Christoph Hellwig wrote:
>
> >
> > (a) the dma_is_direct() function/macro uses "likely()" for the test
>
> I'm a little worried about that. Yes, for the common case it is
> likely. But if you run a setup where you say always have an iommu
> it is not, in fact it
On Thu, Dec 06, 2018 at 06:10:47PM +, Robin Murphy wrote:
> AFAICS the tmp list wasn't about locking as much as meaning that if
> kzalloc() failed at any point, we can free the partial allocation and back
> out without disturbing free_entries at all - that still makes sense to me
> up until
On Thu, Dec 06, 2018 at 10:29:35AM -0800, Nadav Amit wrote:
> Did you happen to see my RFC for "automatic" indirect call promotion?
>
> https://lkml.org/lkml/2018/10/18/175
>
> I hope to get v1 based on Josh responses next week.
I'll take a look when you repost it. Although I'm always a
On Thu, Dec 06, 2018 at 10:28:22AM -0800, Linus Torvalds wrote:
> which is counterproductive because it checks for the fast case *after*
> you've done a load (and a check) that is entirely pointless for the
> fast case.
>
> Put another way, you made the fast case unnecessarily slow.
>
> If this
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
drivers/iommu/dma-iommu.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
On Thu, Dec 06, 2018 at 06:40:27PM +0100, Jesper Dangaard Brouer wrote:
> Is this patch to be applied on top of the other (41) patches I just
> tested with my XDP forward workload?
This is just the last patch of the git tree you tested. All the
others were sent out separately already.
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
On 06/12/2018 14:24, Christoph Hellwig wrote:
@@ -47,6 +47,8 @@
#ifndef PREALLOC_DMA_DEBUG_ENTRIES
#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
#endif
FYI, I think we should drop the potential arch hook with the ifndef
here once we support the dynamic adjustment.
Sure - I have a vague
On Thu, Dec 6, 2018 at 10:28 AM Linus Torvalds
wrote:
>
> Put another way, you made the fast case unnecessarily slow.
Side note: the code seems to be a bit confused about it, because
*some* cases test the fast case first, and some do it after they've
already accessed the pointer for the slow
> On Dec 6, 2018, at 9:43 AM, Jesper Dangaard Brouer wrote:
>
> On Thu, 6 Dec 2018 07:37:19 -0800
> Christoph Hellwig wrote:
>
>> Hi all,
>>
>> a while ago Jesper reported major performance regressions due to the
>> spectre v2 mitigations in his XDP forwarding workloads. A large part
>> of
On 06/12/2018 14:23, Christoph Hellwig wrote:
+static int dma_debug_add_entries(u32 num_entries, gfp_t gfp)
+{
+ struct dma_debug_entry *entry, *next_entry;
+ LIST_HEAD(tmp);
+ int i;
+
+ for (i = 0; i < num_entries; ++i) {
+ entry = kzalloc(sizeof(*entry),
On Thu, 6 Dec 2018 07:37:19 -0800
Christoph Hellwig wrote:
> Hi all,
>
> a while ago Jesper reported major performance regressions due to the
> spectre v2 mitigations in his XDP forwarding workloads. A large part
> of that is due to the DMA mapping API indirect calls.
>
> It turns out that
On Thu, 6 Dec 2018 07:37:20 -0800
Christoph Hellwig wrote:
> Avoid expensive indirect calls in the fast path DMA mapping
> operations by directly calling the dma_direct_* ops if we are using
> the directly mapped DMA operations.
>
> Signed-off-by: Christoph Hellwig
> ---
>
On 06/12/2018 15:35, Joerg Roedel wrote:
Hi Robin,
On Wed, Dec 05, 2018 at 05:17:54PM +, Robin Murphy wrote:
FWIW, this check (and its ACPI equivalent in patch #3) is specifically
asking "has .add_device() already been called?", rather than the more
general "is this device managed by an
Please don’t merge this code. We are still testing and trying to figure out
where the problems are in the code.
— Christian
Sent from my iPhone
> On 6. Dec 2018, at 11:55, Christian Zigotzky wrote:
>
>> On 05 December 2018 at 3:05PM, Christoph Hellwig wrote:
>>
>> Thanks. Can you try a few
Hi Dongli,
Maybe move d_swiotlb_usage declare into swiotlb_create_debugfs():
void swiotlb_create_debugfs(void)
{
#ifdef CONFIG_DEBUG_FS
static struct dentry *d_swiotlb_usage = NULL;
if (d_swiotlb_usage)
return;
d_swiotlb_usage =
On Wed, Dec 05, 2018 at 06:49:26PM +, Robin Murphy wrote:
> if (ops && dev->bus && !dev->iommu_group)
>
> What I can't quite remember just now is whether it's actually valid to get
> here with err == 0 but dev->iommu_fwspec->ops == NULL, so it *might* be OK
> to use "!err" instead of
On Wed, Dec 05, 2018 at 06:20:50PM +, Robin Murphy wrote:
> Is there any good reason to let .add_device/.remove_device be optional
> still? Everyone's implemented them for a while now, and on a practical level
> I don't really see how else we could expect devices to be taken in and out
> of
On Thu, Dec 06, 2018 at 01:55:20PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 04, 2018 at 06:25:00PM +0100, Joerg Roedel wrote:
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Joerg Roedel
> > ---
> > include/linux/device.h | 10 ++
> > 1 file changed, 10 insertions(+)
>
> Acked-by:
Avoid expensive indirect calls in the fast path DMA mapping
operations by directly calling the dma_direct_* ops if we are using
the directly mapped DMA operations.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 17 -
include/linux/dma-mapping.h | 138
Hi all,
a while ago Jesper reported major performance regressions due to the
spectre v2 mitigations in his XDP forwarding workloads. A large part
of that is due to the DMA mapping API indirect calls.
It turns out that the most common implementation of the DMA API is the
direct mapping case, and
On Wed, Dec 05, 2018 at 05:17:29PM +, Robin Murphy wrote:
> On 04/12/2018 17:24, Joerg Roedel wrote:
> Nice, we can also clean up a whole load of vague iommu_present() usage and
> even one or two odd iommu_get_domain_for_dev() calls once we have this.
Right, I didn't think of that yet, but
I've picked this up for the dma-mapping for-next tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks like generic-y is mostly going away anyway, so I'm going to skip
this to avoid conflicts with the kbuild tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
I've pulled this into the dma-mapping for-next tree, with the suggestion
from Robin that improves bisectability, and two unused variables found
by the build bot.
___
iommu mailing list
iommu@lists.linux-foundation.org
This looks very nice, thanks!
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Dec 05, 2018 at 07:56:56PM +, Robin Murphy wrote:
> 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
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> @@ -47,6 +47,8 @@
> #ifndef PREALLOC_DMA_DEBUG_ENTRIES
> #define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
> #endif
FYI, I think we should drop the potential arch hook with the ifndef
here once we support the dynamic adjustment.
> + if
> +static int dma_debug_add_entries(u32 num_entries, gfp_t gfp)
> +{
> + struct dma_debug_entry *entry, *next_entry;
> + LIST_HEAD(tmp);
> + int i;
> +
> + for (i = 0; i < num_entries; ++i) {
> + entry = kzalloc(sizeof(*entry), gfp);
> + if (!entry)
> +
On Wed, Dec 05, 2018 at 05:41:51PM +, Robin Murphy wrote:
> Nit: I think it makes sense to put this inside the "if (!err)" condition
> below rather than out here where it may or may not be relevant. The comment
> for that case is already supposed to imply that it's dealing with a fresh
>
On Wed, Dec 05, 2018 at 07:56:51PM +, Robin Murphy wrote:
> 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
ping?
On Wed, Nov 14, 2018 at 09:22:48AM +0100, Christoph Hellwig wrote:
> vio_dma_mapping_ops currently does a lot of indirect calls through
> dma_iommu_ops, which not only make the code harder to follow but are
> also expensive in the post-spectre world. Unwind the indirect calls
> by calling
ping?
On Wed, Nov 14, 2018 at 09:22:54AM +0100, Christoph Hellwig wrote:
> If dart_init failed we didn't have a chance to setup dma or controller
> ops yet, so there is no point in resetting them.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/sysdev/dart_iommu.c | 11 +--
>
ping?
On Wed, Nov 14, 2018 at 09:22:59AM +0100, Christoph Hellwig wrote:
> The CXL code never even looks at the dma mask, so there is no good
> reason for this sanity check. Remove it because it gets in the way
> of the dma ops refactoring.
>
> Signed-off-by: Christoph Hellwig
> ---
>
ping?
On Wed, Nov 14, 2018 at 09:22:46AM +0100, Christoph Hellwig wrote:
> The implemementation for the CONFIG_NOT_COHERENT_CACHE case doesn't share
> any code with the one for systems with coherent caches. Split it off
> and merge it with the helpers in dma-noncoherent.c that have no other
>
ping?
On Wed, Nov 14, 2018 at 09:22:43AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/include/asm/dma-mapping.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h
>
ping?
On Wed, Nov 14, 2018 at 09:22:45AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/kernel/dma-iommu.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
> index
ping?
On Wed, Nov 14, 2018 at 09:22:47AM +0100, Christoph Hellwig wrote:
> These methods are optional, no need to implement no-op versions.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/kernel/dma.c | 16
> 1 file changed, 16
ping?
On Wed, Nov 14, 2018 at 09:22:44AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> Acked-by: Benjamin Herrenschmidt
> ---
> arch/powerpc/kernel/setup_32.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/setup_32.c
Ben / Michael,
can we get this one queued up for 4.21 to prepare for the DMA work later
on?
On Wed, Nov 14, 2018 at 09:22:41AM +0100, Christoph Hellwig wrote:
> Powerpc has somewhat odd usage where ZONE_DMA is used for all memory on
> common 64-bit configfs, and ZONE_DMA32 is used for 31-bit
powerpc maintainers, can you pick this up as this is a bug fix for the
currently existing powerpc Kconfig code?
On Wed, Nov 14, 2018 at 09:22:42AM +0100, Christoph Hellwig wrote:
> AMIGAONE select NOT_COHERENT_CACHE, so we better allow it.
>
> Signed-off-by: Christoph Hellwig
> ---
>
Hi Robin,
On Wed, Dec 05, 2018 at 05:50:23PM +, Robin Murphy wrote:
> This needs to reload the new fwspec initialised by iort_iommu_xlate(), in
> the same manner as the OF code. I think the best thing to do is encapsulate
> the dev_iommu_fwspec_get() call in iort_fwspec_iommu_ops(), and have
On Tue, Dec 04, 2018 at 05:29:56PM +0100, 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: Will Deacon
> Cc: Robin Murphy
>
On Tue, Dec 04, 2018 at 06:25:00PM +0100, Joerg Roedel wrote:
> 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
On 05 December 2018 at 3:05PM, Christoph Hellwig wrote:
Thanks. Can you try a few stepping points in the tree?
First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
(the first one) applied?
Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b
And if that still
On Thu, Dec 6, 2018 at 5:37 PM Vlastimil Babka wrote:
>
> On 12/6/18 4:49 AM, Nicolas Boichat wrote:
> >> So it would be fine even unchanged. The check would anyway need some
> >> more love to catch the same with __GFP_DMA to be consistent and cover
> >> all corner cases.
> > Yes, the test is not
On 12/6/18 4:49 AM, Nicolas Boichat wrote:
>> So it would be fine even unchanged. The check would anyway need some
>> more love to catch the same with __GFP_DMA to be consistent and cover
>> all corner cases.
> Yes, the test is not complete. If we really wanted this to be
> accurate, we'd need to
64 matches
Mail list logo
