Hi Janusz,
On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
We should avoid kernel panic when a intel_unmap() is called against
a non-existent domain.
Does that mean you suggest to replace
BUG_ON(!domain);
with something like
if (WARN_ON(!domain))
return;
and to no
Dear Bhupesh,
On 28.08.19 21:54, Bhupesh Sharma wrote:
Hi Donald,
On Wed, Aug 28, 2019 at 8:38 PM Donald Buczek wrote:
On 8/20/19 11:21 PM, Donald Buczek wrote:
Dear Linux folks,
I'm investigating a problem, that the crash utility fails to work with our
crash dumps:
buczek@kreios:/
Hi Joerg,
On Fri, Aug 23, 2019 at 03:54:40PM +0100, Will Deacon wrote:
> Please pull these ARM SMMU updates for 5.4. The branch is based on the
> for-joerg/batched-unmap branch that you pulled into iommu/core already
> because I didn't want to rebase everything onto -rc3. The pull request
> was ge
When running heavy memory pressure workloads, the system is throwing
endless warnings,
smartpqi :23:00.0: AMD-Vi: IOMMU mapping error in map_sg (io-pages:
5 reason: -12)
Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40
07/10/2019
swapper/10: page allocation failure: order
Hi Donald,
On Wed, Aug 28, 2019 at 8:38 PM Donald Buczek wrote:
>
> On 8/20/19 11:21 PM, Donald Buczek wrote:
> > Dear Linux folks,
> >
> > I'm investigating a problem, that the crash utility fails to work with our
> > crash dumps:
> >
> > buczek@kreios:/mnt$ crash vmlinux crash.vmcore
> >
On Wed, Aug 28, 2019 at 11:21:53AM -0700, Kuppuswamy Sathyanarayanan wrote:
> On Mon, Aug 19, 2019 at 06:19:25PM -0500, Bjorn Helgaas wrote:
> > On Mon, Aug 19, 2019 at 03:53:31PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > > On Mon, Aug 19, 2019 at 09:15:00AM -0500, Bjorn Helgaas wrote:
> > > > O
On Mon, Aug 19, 2019 at 06:19:25PM -0500, Bjorn Helgaas wrote:
> On Mon, Aug 19, 2019 at 03:53:31PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > On Mon, Aug 19, 2019 at 09:15:00AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Aug 15, 2019 at 03:39:03PM -0700, Kuppuswamy Sathyanarayanan
> > > wrote:
>
On Wed, 2019-08-28 at 16:14 +0200, Christoph Hellwig wrote:
> Various helpers need the pci_sysdata just to dereference a single field
> in it. Add a little helper that returns the properly typed sysdata
> pointer to require a little less boilerplate code.
>
> Signed-off-by: Christoph Hellwig
> -
On 8/20/19 11:21 PM, Donald Buczek wrote:
Dear Linux folks,
I'm investigating a problem, that the crash utility fails to work with our
crash dumps:
buczek@kreios:/mnt$ crash vmlinux crash.vmcore
crash 7.2.6
Copyright (C) 2002-2019 Red Hat, Inc.
Copyright (C) 2004, 2005, 20
On Wed, Aug 28, 2019 at 07:14:42AM -0700, Christoph Hellwig wrote:
> With a little tweak to the intel-iommu code we should be able to work
> around the VMD mess for the requester IDs without having to create giant
> amounts of boilerplate DMA ops wrapping code. The other advantage of
> this scheme
On Wednesday, August 28, 2019 2:56:18 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 8/27/19 5:35 PM, Janusz Krzysztofik wrote:
> > Hi Lu,
> >
> > On Monday, August 26, 2019 10:29:12 AM CEST Lu Baolu wrote:
> >> Hi Janusz,
> >>
> >> On 8/26/19 4:15 PM, Janusz Krzysztofik wrote:
> >>> Hi Lu,
> >>>
>
Store the actual VMD device in struct pci_sysdata, so that we can later
use it directly for DMA mappings.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/pci.h | 5 ++---
drivers/pci/controller/vmd.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/incl
Various helpers need the pci_sysdata just to dereference a single field
in it. Add a little helper that returns the properly typed sysdata
pointer to require a little less boilerplate code.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/pci.h | 28 +---
1 file
With a little tweak to the intel-iommu code we should be able to work
around the VMD mess for the requester IDs without having to create giant
amounts of boilerplate DMA ops wrapping code. The other advantage of
this scheme is that we can respect the real DMA masks for the actual
devices, and I be
There are no users of X86_DEV_DMA_OPS left, so remove the code.
Signed-off-by: Christoph Hellwig
---
arch/x86/Kconfig | 3 ---
arch/x86/include/asm/device.h | 10 -
arch/x86/pci/common.c | 38 ---
3 files changed, 51 deletions(-)
dif
Hi all,
this is a new version of the vmd dma_map_ops removal, which does not
require vmd to be built in. Instead we slightly expand the vmd-specific
field in the x86 pci_sysdata to cover that information.
Note that I do not have a vmd-enable system, so some testing by the
maintainers would be we
Non-UAPI headers can't be included by userspace, so remove the
pointless ifdef.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/pci.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index e662f987dfa2..6fa846920f5f 100644
--
In commit 14bd9a607f90 ("iommu/iova: Separate atomic variables
to improve performance") Jinyu Qi identified that the atomic_cmpxchg()
in queue_iova() was causing a performance loss and moved critical fields
so that the false sharing would not impact them.
However, avoiding the false sharing in the
When the max_segs of a mmc host is smaller than 512, the mmc
subsystem tries to use 512 segments if DMA MAP layer can merge
the segments, and then the mmc subsystem exposes such information
to the block layer by using blk_queue_can_use_dma_map_merging().
Signed-off-by: Yoshihiro Shimoda
Reviewed-
This patch adds a new dma_map_ops of get_merge_boundary() to
expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Simon Horman
Acked-by: Joerg Roedel
---
drivers/iommu/dma-iommu.c | 8
1 file changed, 8 insertions(+)
diff
This patch adds a new DMA API "dma_get_merge_boundary". This function
returns the DMA merge boundary if the DMA layer can merge the segments.
This patch also adds the implementation for a new dma_map_ops pointer.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Christoph Hellwig
Reviewed-by: Simon
This patch adds a helper function whether a queue can merge
the segments by the DMA MAP layer (e.g. via IOMMU).
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Christoph Hellwig
Reviewed-by: Simon Horman
#include
#include
+#include
#include "blk.h"
#include "blk-wbt.h"
@@ -832,6 +833,28
This patch series is based on linux-next.git / next-20190828 tag.
Since SDHI host internal DMAC of the R-Car Gen3 cannot handle two or
more segments, the performance rate (especially, eMMC HS400 reading)
is not good. However, if IOMMU is enabled on the DMAC, since IOMMU will
map multiple scatter
On Wed, Aug 28, 2019 at 7:53 PM Masahiro Yamada
wrote:
>
> Hi Christoph,
>
> On Tue, Aug 27, 2019 at 8:55 PM Christoph Hellwig wrote:
> >
> > On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> > > Yes, this makes my driver working again
> > > when CONFIG_DMA_CMA=y.
> > >
> > >
> >
On 28/08/2019 13:49, Robin Murphy wrote:
> Hi Neil,
>
> On 28/08/2019 12:28, Neil Armstrong wrote:
>> Hi Robin,
>>
[...]
>>>
>>> OK - with the 32-bit hack pointed to up-thread, a quick kmscube test gave
>>> me the impression that T720 works fine, but on closer inspection some parts
>>> of glmar
Hi Neil,
On 28/08/2019 12:28, Neil Armstrong wrote:
Hi Robin,
On 31/05/2019 15:47, Robin Murphy wrote:
On 31/05/2019 13:04, Tomeu Vizoso wrote:
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
On 29/05/2019 16:09, Tomeu Vizoso wrote:
On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
Hi Robyn,
On 31/05/2019 15:47, Robin Murphy wrote:
> On 31/05/2019 13:04, Tomeu Vizoso wrote:
>> On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>>>
>>> On 29/05/2019 16:09, Tomeu Vizoso wrote:
On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
>
[snip]
> [ 345.204813] panfr
Hi Christoph,
On Tue, Aug 27, 2019 at 8:55 PM Christoph Hellwig wrote:
>
> On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> > Yes, this makes my driver working again
> > when CONFIG_DMA_CMA=y.
> >
> >
> > If I apply the following, my driver gets back working
> > irrespective of
On Mon, 2019-08-26 at 15:46 +0200, Nicolas Saenz Julienne wrote:
> On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote:
> > On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote:
> > > Some architectures have platform specific DMA addressing limitations.
> > > This will allo
29 matches
Mail list logo
