On Wed, 10 Apr 2019 22:02:01 -0500
Josh Poimboeuf wrote:
> > #ifdef CONFIG_STACKTRACE
> > - struct stack_trace stacktrace;
> > - unsigned longst_entries[DMA_DEBUG_STACKTRACE_ENTRIES];
> > + unsigned intst_len;
> > + unsigned long st_entries[DMA_DEBUG_STACKTRACE_ENTRIE
On Wed, Apr 10, 2019 at 12:28:22PM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace with an invocation of
> the storage array based interface.
>
> Signed-off-by: Thomas Gleixner
> Cc: iommu@lists.linux-foundation.org
> Cc: Robin Murphy
> Cc: Christoph Hellwig
>
With skip set to 1, I get a traceback like this:
[ 106.867637] DMA-API: Mapped at:
[ 106.870784] afu_dma_map_region+0x2cd/0x4f0 [dfl_afu]
[ 106.875839] afu_ioctl+0x258/0x380 [dfl_afu]
[ 106.880108] do_vfs_ioctl+0xa9/0x720
[ 106.883688] ksys_ioctl+0x60/0x90
[ 106.887007] __x64_sys_ioctl+
On Tue, 9 Apr 2019 20:37:55 +0300
Andriy Shevchenko wrote:
> On Tue, Apr 09, 2019 at 09:43:28AM -0700, Jacob Pan wrote:
> > On Tue, 9 Apr 2019 13:07:18 +0300
> > Andriy Shevchenko wrote:
> > > On Mon, Apr 08, 2019 at 04:59:23PM -0700, Jacob Pan wrote:
>
> > > > +int iommu_cache_invalidate(s
From: Christoph Hellwig
Date: Wed, 10 Apr 2019 18:54:30 +0200
> Dave, are you going to pick this up through the sparc tree, or do
> you expect me to send it through the dma-mapping one?
Please take it through dma-mapping as I'm a bit overloaded right now
and that would therefore help me a lot.
Dave, are you going to pick this up through the sparc tree, or do
you expect me to send it through the dma-mapping one?
On Thu, Apr 04, 2019 at 06:25:38PM +0200, Christoph Hellwig wrote:
> Now that we allow drivers to always need to set larger than required
> DMA masks we need to be a little more
The AMD iommu dma_ops are only attached on a per-device basis when an
actual translation is needed. Remove the leftover bypass support which
in parts was already broken (e.g. it always returns 0 from ->map_sg).
Use the opportunity to remove a few local variables and move assignments
into the decl
We already do this in the caller.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel-iommu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 497217cb0880..b7fd297a3c23 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/
The intel-iommu driver currently has a partial reimplementation
of the direct mapping code for devices that use pass through
mode. Replace that code with calls to the relevant dma_direct
routines at the highest level. This means we have exactly the
same behvior as the dma direct code itself, and
Hi Dave and Joerg,
below are three relatively simple patches to clean up the
bypass case and make it share more code with the dma-direct
implementation.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/lis
Invert the return value to avoid double negatives, use a bool
instead of int as the return value, and reduce some indentation
after early returns.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/intel-iommu.c | 47 +
1 file changed, 21 insertions(+), 26 del
Hi Marc,
Few comments inline.
On 3/28/19 7:06 PM, Marc Gonzalez wrote:
> Add MSM8998 PCIe QMP PHY and PCIe root complex DT nodes.
>
> Signed-off-by: Marc Gonzalez
> ---
> arch/arm64/boot/dts/qcom/msm8998.dtsi | 78 +++
> 1 file changed, 78 insertions(+)
>
> diff --git
Commit e5567f5f6762 ("PCI/ATS: Add pci_prg_resp_pasid_required()
interface.") added a common interface to check the PASID bit in the PRI
capability. Use it in the AMD driver.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/amd_iommu.c | 19 +--
1 file changed, 1 insertion(
This is the device driver API for SVA (Shared Virtual Addressing).
Since v2 I removed the set_sva_ops() IOMMU operation as suggested by
Joerg, instead doing the sva_ops assignment in iommu.c.
The four dev_feature functions are implemented by Lu Baolu's IOMMU-aware
mdev series [2].
iommu_d
Add bind() and unbind() operations to the IOMMU API.
iommu_sva_bind_device() binds a device to an mm, and returns a handle to
the bond, which is released by calling iommu_sva_unbind_device().
Each mm bound to devices gets a PASID (by convention, a 20-bit system-wide
ID representing the address spa
On Wed, 2019-04-10 at 08:43 +0200, h...@lst.de wrote:
> On Tue, Apr 09, 2019 at 05:24:48PM +, Thomas Hellstrom wrote:
> > > Note that this only affects external, untrusted devices. But
> > > that
> > > may include eGPU,
> >
> > What about discrete graphics cards, like Radeon and Nvidia? Who
>
Hi Vincent,
On 10/04/2019 13:35, Vincent Stehlé wrote:
> On Thu, Apr 04, 2019 at 08:55:25AM +0200, Auger Eric wrote:
>> Hi Marc, Robin, Alex,
> (..)
>> Do you think this is a reasonable assumption to consider devices within
>> the same host iommu group share the same MSI doorbell?
>
> Hi Eric,
>
Hi Vincent,
On 4/10/19 2:35 PM, Vincent Stehlé wrote:
> On Thu, Apr 04, 2019 at 08:55:25AM +0200, Auger Eric wrote:
>> Hi Marc, Robin, Alex,
> (..)
>> Do you think this is a reasonable assumption to consider devices within
>> the same host iommu group share the same MSI doorbell?
>
> Hi Eric,
>
Hi,
I was working on an issue [1] triggered by MDEV passthrough to a KVM Guest.
I got recommended to try intel_iommu=igfx_off and it worked like a
charm allowing me to run opencl things in the guest on the device.
[2] still states for intel_iommu=igfx_off "If this fixes anything,
please ensure you
On Tue, 9 Apr 2019, Zhen Lei wrote:
> s390_iommu=strict is equivalent to iommu.dma_mode=strict.
>
> Signed-off-by: Zhen Lei
Acked-by: Sebastian Ott
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/list
On Thu, Apr 04, 2019 at 08:55:25AM +0200, Auger Eric wrote:
> Hi Marc, Robin, Alex,
(..)
> Do you think this is a reasonable assumption to consider devices within
> the same host iommu group share the same MSI doorbell?
Hi Eric,
I am not sure this assumption always hold.
Marc, Robin and Alex can
On Wed, 10 Apr 2019 14:08:19 +0200 (CEST)
Thomas Gleixner wrote:
> On Wed, 10 Apr 2019, Christoph Hellwig wrote:
> >
> > Please always send the whole series out to everyone on the To and Cc
> > list, otherwise patch series are not reviewable.
>
> Bah. People complain about overly broad cc-li
On Wed, 10 Apr 2019, Christoph Hellwig wrote:
> On Wed, Apr 10, 2019 at 12:28:22PM +0200, Thomas Gleixner wrote:
> > Replace the indirection through struct stack_trace with an invocation of
> > the storage array based interface.
>
> This seems to be missing some context, at least stack_trace_save
On Wed, 10 Apr 2019 at 12:20, Steven Price wrote:
>
> On 08/04/2019 22:04, Rob Herring wrote:
> > On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
> >>
> >> On 01/04/2019 08:47, Rob Herring wrote:
> >>> This adds the initial driver for panfrost which supports Arm Mali
> >>> Midgard and Bifrost
On Wed, Apr 10, 2019 at 12:28:22PM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace with an invocation of
> the storage array based interface.
This seems to be missing some context, at least stack_trace_save does
not actually exist in mainline.
Please always send
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: iommu@lists.linux-foundation.org
Cc: Robin Murphy
Cc: Christoph Hellwig
Cc: Marek Szyprowski
---
kernel/dma/debug.c | 13 +
1 file chang
On 09/04/2019 17:15, Rob Herring wrote:
> On Tue, Apr 9, 2019 at 10:56 AM Tomeu Vizoso
> wrote:
>>
>> On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
>>>
>>> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
On 01/04/2019 08:47, Rob Herring wrote:
> This adds the initial driver f
On 08/04/2019 22:04, Rob Herring wrote:
> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>>
>> On 01/04/2019 08:47, Rob Herring wrote:
>>> This adds the initial driver for panfrost which supports Arm Mali
>>> Midgard and Bifrost family of GPUs. Currently, only the T860 and
>>> T760 Midgard GPU
On Wed, Apr 10, 2019 at 10:44:03AM +0100, Robin Murphy wrote:
> Hi Dan,
>
> On 10/04/2019 10:34, Dan Carpenter wrote:
> > Hello Jean-Philippe Brucker,
> >
> > This is a semi-automatic email about new static checker warnings.
> >
> > The patch fac83d29d954: "iommu/io-pgtable-arm: Fix pgtable allo
Hi Dan,
On 10/04/2019 10:34, Dan Carpenter wrote:
Hello Jean-Philippe Brucker,
This is a semi-automatic email about new static checker warnings.
The patch fac83d29d954: "iommu/io-pgtable-arm: Fix pgtable allocation
in selftest" from Jun 18, 2018, leads to the following Smatch
complaint:
Hello Jean-Philippe Brucker,
This is a semi-automatic email about new static checker warnings.
The patch fac83d29d954: "iommu/io-pgtable-arm: Fix pgtable allocation
in selftest" from Jun 18, 2018, leads to the following Smatch
complaint:
drivers/iommu/io-pgtable-arm.c:246 __arm_lpae_alloc_pa
On 09/04/2019 23:47, Nicolin Chen wrote:
Hi all,
According to the routine of iommu_dma_alloc(), it allocates an iova
then does iommu_map() to map the iova to a physical address of new
allocated pages. However, in remoteproc_core.c, I see its code try
to iommu_map() without having an alloc_iova()
32 matches
Mail list logo
